1
00:01:58,040 -->
00:02:01,235
Welcome to another episode of Empower Apps. I'm your host Leo Dion.
2
00:02:02,000 -->
00:02:04,180
Today, I’m excited to be joined by Mohammad Azam.
3
00:02:04,210 -->
00:02:07,020
Mohammad, thank you so much for making the time to come on.
4
00:02:07,200 -->
00:02:09,000
Thank you for having me, Leo.
5
00:02:10,010 -->
00:02:12,190
You're otherwise known on Twitter as Azam Sharp,
6
00:02:12,200 -->
00:02:16,140
but I'll let you go ahead and introduce yourself before we get started.
7
00:02:17,050 -->
00:02:23,060
Sure. I started programming awhile back with asp.net, .Net, and all this stuff.
8
00:02:23,070 -->
00:02:31,150
But for iOS world, I joined in 2010 when my colleague introduced me to Mac
9
00:02:31,180 -->
00:02:35,100
and iPhone, and all those cool things with Objective C.
10
00:02:35,190 -->
00:02:41,080
And from there on I started learning Objective C with all those memory management,
11
00:02:41,085 -->
00:02:46,120
manual memory management stuff with 3.2 or 3 point something at that time.
12
00:02:46,220 -->
00:02:55,040
Fast forward to today I have been teaching online on Udemy as well as on YouTube.
13
00:02:55,045 -->
00:03:04,060
But my main job is to be a coding bootcamp instructor for a company called Digital Crafts where I teach web development
14
00:03:04,160 -->
00:03:11,130
which includes JavaScript, Node, Express, React, Redux, PostgreSQL, and all these kind of things.
15
00:03:11,140 -->
00:03:13,110
So that's what I'm doing these days.
16
00:03:13,220 -->
00:03:16,050
Awesome. I'm so glad to have you on.
17
00:03:17,200 -->
00:03:21,020
Today we're going to be talking about one particular thing that you've been...
18
00:03:21,030 -->
00:03:25,245
You have a new Udemy course I believe on server-driven UI.
19
00:03:25,250 -->
00:03:31,160
Do you want to explain what that is before we get started and jumping into how it works?
20
00:03:32,230 -->
00:03:39,240
Sure. The main concept behind server-driven UI is that instead of only the data coming from the server
21
00:03:39,245 -->
00:03:43,060
which you can just display on your iPhone app,
22
00:03:43,230 -->
00:03:50,030
you are also be getting data plus the components that you want to display on the UI.
23
00:03:50,110 -->
00:03:56,140
You may want to say that the server is going to send a carousel control or a carousel
24
00:03:56,220 -->
00:04:01,030
framework or anything like that, like a JSON respond which includes carousel.
25
00:04:01,090 -->
00:04:05,110
You want to display a carousel and the server can decide that
26
00:04:05,130 -->
00:04:10,090
I want to display a rating control which will go from 1 to 5, or 5 to 10, or whatever.
27
00:04:10,180 -->
00:04:17,060
The main idea of the server is not only in charge of the data that your app will display
28
00:04:17,120 -->
00:04:25,180
but also the components, the views, the actual small widgets that you want to display in your application.
29
00:04:25,230 -->
00:04:27,200
So that's the basic gist of it.
30
00:04:28,180 -->
00:04:33,110
So if I’m understanding this correctly like...
31
00:04:35,060 -->
00:04:41,040
Is there a certain use case where this might be a good fit as opposed to others?
32
00:04:41,180 -->
00:04:48,060
Sure. This is a very good question because this is not for all the different apps that you're going to design.
33
00:04:48,140 -->
00:04:54,080
This is only for very, very particular kind of apps that require a dynamic interface
34
00:04:54,160 -->
00:05:00,090
that needs to be changed quickly without going through the trouble of app review and all those things.
35
00:05:00,200 -->
00:05:06,200
It’s also very, very beneficial for those apps that are available on many different platforms.
36
00:05:07,000 -->
00:05:13,030
So if you are a very big company and we can take example of Uber, Airbnb, and Spotify
37
00:05:13,110 -->
00:05:16,170
and they have apps on iOS, Android, and web.
38
00:05:16,240 -->
00:05:21,120
And they want to update the apps all of them at the same exact time instantly
39
00:05:21,210 -->
00:05:26,220
then they can use this approach without publishing one version on iOS app store,
40
00:05:26,225 -->
00:05:29,230
one version on Android, and one deployment for web.
41
00:05:29,235 -->
00:05:34,140
They can simply change the structure the server is returning
42
00:05:34,170 -->
00:05:39,160
and all of the clients (iOS, Android, and web) will immediately be updated.
43
00:05:39,170 -->
00:05:44,050
So it's very small set of apps that will need this kind of feature.
44
00:05:44,100 -->
00:05:50,170
I'm not saying that your app may not be the one because maybe some parts of your app will also need this feature.
45
00:05:50,175 -->
00:05:56,140
So it doesn't have to be 100% meaning your app doesn't have to be 100% server-driven.
46
00:05:56,220 -->
00:06:01,250
Maybe parts of the app are server driven and parts are just normal app.
47
00:06:04,200 -->
00:06:08,200
It seemed based on some of your content, and Airbnb was the big article
48
00:06:08,205 -->
00:06:12,190
I saw on medium where they had really proposed this idea.
49
00:06:13,140 -->
00:06:20,240
It seems to me like a good situation is where you have tons of dynamic content that you kind of have...
50
00:06:21,150 -->
00:06:24,090
For instance, Airbnb is a great example. We'll use that.
51
00:06:25,070 -->
00:06:31,050
But you might have a place you want to rent out and you might want to add a widget for certain rentals.
52
00:06:32,120 -->
00:06:41,100
That might make sense to where you code the widget in Kotlin, HTML, or Node, or Swift.
53
00:06:42,060 -->
00:06:46,170
And then, you have the server side just give you, “Hey, we need this particular widget here”,
54
00:06:46,175 -->
00:06:51,020
and then it knows how to render that widget out on each individual operating system.
55
00:06:51,060 -->
00:06:57,180
That’s it where you large amount of content and where you want to customize, have a template,
56
00:06:57,185 -->
00:07:03,190
and then each individual OS designs it, or platform I should say, renders that out correctly
57
00:07:03,195 -->
00:07:06,090
based on when it gets back from the server. Does that sound about right?
58
00:07:06,210 -->
00:07:13,250
Yeah. Just one thing to keep in mind is that all the widgets or components which you're trying to render
59
00:07:14,050 -->
00:07:18,185
they should already be part of the binary that you distributed to the app store.
60
00:07:19,050 -->
00:07:22,230
Because all that's... Basically what you're simply changing is that...
61
00:07:23,020 -->
00:07:29,070
The server is simply saying that, “Oh, on this particular page now I don't want to display the rating control.
62
00:07:29,075 -->
00:07:34,000
I want to display a drop down list control.” But that drop-down list and the rating control
63
00:07:34,070 -->
00:07:38,200
must already be part of the binary that you have deployed to the app store.
64
00:07:39,090 -->
00:07:44,030
So you're basically changing the ordering, changing the color or some features,
65
00:07:44,060 -->
00:07:47,050
so those things you can do on the remote side meaning the server.
66
00:07:47,190 -->
00:07:50,080
What got you interested in this particular topic?
67
00:07:51,010 -->
00:07:58,160
I've always been a server or a back-end developer with my days in asp.net and back-end development with all the stuff.
68
00:07:59,090 -->
00:08:06,130
And these days also I do Node development, Express, and all of that. Vapor also with the server-side Swift.
69
00:08:06,200 -->
00:08:12,110
I was always interested in these cases. And if you can believe it we actually implemented this
70
00:08:12,160 -->
00:08:17,150
back in 2005 and 2006 but not using JSON.
71
00:08:17,210 -->
00:08:22,040
- We did it in a very weird way. It didn't really work out because we're actually...
- XML?
72
00:08:22,140 -->
00:08:29,270
XML. We were storing XML I think for part of it there were some pages that were just pure HTML.
73
00:08:30,020 -->
00:08:37,190
They were in databases and it was very hard to obviously edit when you have pure HTML in there.
74
00:08:37,210 -->
00:08:39,100
But, yeah, we did it in XML.
75
00:08:40,060 -->
00:08:45,130
One of the big use cases like you said is the cross platform ability too.
76
00:08:45,140 -->
00:08:51,160
And I agree completely. We did an episode on cross-platform development with Rob Kerr a couple of years ago.
77
00:08:51,165 -->
00:09:00,120
To me this is the ideal. Instead of React necessarily or whatever other flutter you might be using,
78
00:09:00,130 -->
00:09:08,020
this might be the best fit for a cross-platform situation just based on what I've seen so far.
79
00:09:09,030 -->
00:09:12,250
Are there any other good use cases besides that that you can think of?
80
00:09:13,080 -->
00:09:19,240
I think the other use cases for this apart from being able to change the interface remotely
81
00:09:20,040 -->
00:09:27,215
and able to deploy instantly on different platforms it definitely helps with AB testing.
82
00:09:28,000 -->
00:09:30,080
Because all you need to do is to simply
83
00:09:31,040 -->
00:09:37,010
view a different version or change the URL and now the client, meaning your iOS, or Android, or web apps,
84
00:09:37,150 -->
00:09:40,200
they will be getting a completely different look and feel.
85
00:09:40,240 -->
00:09:46,110
You can test it out without deploying or doing those weird things that you do with AB testing
86
00:09:46,115 -->
00:09:50,090
like deploying two different versions and all those kind of if checks and all that stuff.
87
00:09:50,150 -->
00:09:55,240
Without doing all of that you can simply change the version URL and now
88
00:09:56,170 -->
00:10:03,090
two clients will have two different view of the same thing and you can test it out which one works much better.
89
00:10:04,140 -->
00:10:08,080
What are some cons that you can think of with going into…?
90
00:10:08,090 -->
00:10:12,210
What would you say to someone who's like I really want to do this?
91
00:10:12,215 -->
00:10:17,020
Well, there are some things you should think about before you jump into doing server-driven UI.
92
00:10:17,110 -->
00:10:22,100
Yeah. One of the things that is very important with server-driven UI is that
93
00:10:22,105 -->
00:10:26,110
your different teams have to work very, very closely together.
94
00:10:26,190 -->
00:10:31,140
If you have a server team which is completely different from your Android team, iOS team, and web team,
95
00:10:31,200 -->
00:10:37,030
now all of those teams should have team meetings together because they have to come up with some sort of a template
96
00:10:37,100 -->
00:10:43,060
that the server will be returning. And that has to be approved by the server team, iOS, Android, and web team
97
00:10:43,065 -->
00:10:46,240
because all of them will be using the same exact template.
98
00:10:47,050 -->
00:10:54,200
So that has to be constructed and that is one of the things that will take a lot of time
99
00:10:54,210 -->
00:10:58,230
to construct this generic page template.
100
00:10:59,200 -->
00:11:02,040
I want to deep dive into that a little bit more.
101
00:11:02,045 -->
00:11:07,150
What are some other things that teams should be aware of when they're managing something like this?
102
00:11:08,100 -->
00:11:12,140
You said having the same template language, right?
103
00:11:12,150 -->
00:11:17,140
Your JSON has to be a specific way and the server has to spit it out and
104
00:11:18,000 -->
00:11:23,000
and the Android, the web, and the iOS folks all have to be able to parse that correctly.
105
00:11:23,005 -->
00:11:24,150
Is there anything else you can think of?
106
00:11:25,010 -->
00:11:30,040
I think from my… When I was working and obviously I was only working with the iOS apps,
107
00:11:30,045 -->
00:11:35,180
my main concern was the decoding strategies that I will have to use to decode those things.
108
00:11:35,240 -->
00:11:39,010
Because there were a lot of cases where
109
00:11:39,210 -->
00:11:46,050
the template that was being returned from the server, and I was controlling the template also, it was...
110
00:11:46,110 -->
00:11:51,070
You can't really decode it to like a string and any because any is
111
00:11:51,080 -->
00:11:53,240
you can't decode that part because any can be anything.
112
00:11:54,030 -->
00:11:57,060
- Right.
- For that I have to create a
113
00:11:57,140 -->
00:12:03,110
completely a different type like a JSON type or any decodable type which will decode it to some other type.
114
00:12:03,115 -->
00:12:09,220
That was a little bit of a hard part to implement those custom decoding strategies. So those have to be done.
115
00:12:10,050 -->
00:12:13,230
The other thing I was thinking of was doing an enum with an associated type.
116
00:12:13,235 -->
00:12:19,125
So you have widget A is something and then you will one way or another
117
00:12:19,130 -->
00:12:23,080
you're going to have to do some work with manually setting that up.
118
00:12:23,160 -->
00:12:24,170
Yeah, yeah.
119
00:12:24,240 -->
00:12:28,230
What other architecting tips do you have for something like this?
120
00:12:29,110 -->
00:12:36,020
I think the first thing to understand if you're planning to go with this approach
121
00:12:36,080 -->
00:12:41,270
you don't have to take the deep dive into just okay we're just going to do everything, the server-side Swift.
122
00:12:42,010 -->
00:12:47,230
You can't completely think about what portions of your application are supposed to be server-side.
123
00:12:48,040 -->
00:12:51,050
So one of the examples that I always use is that
124
00:12:51,170 -->
00:12:57,180
whenever you're displaying some data especially the read-only data maybe you're displaying some
125
00:12:57,230 -->
00:13:03,110
pet store with some pet adoption pictures, and those kind of things with advertisement on the top,
126
00:13:03,115 -->
00:13:08,070
or some ratings and everything. The read-only portion is a very good example of
127
00:13:08,130 -->
00:13:12,220
that can be done easily with server side because it's just read-only.
128
00:13:13,090 -->
00:13:19,150
You can move up and down. But whenever you go into taking input and processing that input
129
00:13:19,160 -->
00:13:24,040
especially with the SwiftUI with bindables and binding and passing state values
130
00:13:24,080 -->
00:13:30,060
then it becomes close to impossible to do those kind of things because if it's...
131
00:13:30,110 -->
00:13:35,250
It’s basically you’re just rendering those controls that your server is returning you
132
00:13:36,040 -->
00:13:41,060
and you just don't know which control will take what. Some controls maybe just
133
00:13:42,010 -->
00:13:47,080
presentation controls while other controls take a binding expression and that's just not possible to do.
134
00:13:47,085 -->
00:13:53,070
So mostly I have used it for read-only views where you're just dynamically changing the view order.
135
00:13:53,220 -->
00:13:58,040
And that's one of the things that I was thinking about too is there's a granularity to this, right?
136
00:13:58,050 -->
00:14:05,120
You cannot really code this to the tee as far as how much control you give to the server
137
00:14:05,125 -->
00:14:12,030
and then you could also just, like you said, take a step-by-step approach to migrating it over.
138
00:14:12,120 -->
00:14:18,120
Oh yeah. I mean, another example that I implemented in the course also is the list example.
139
00:14:18,130 -->
00:14:24,255
A very simple list but each cell of the list can be very different and that is controlled by the server.
140
00:14:25,030 -->
00:14:30,030
So one cell can be just a text row meaning it just displays the text information
141
00:14:30,050 -->
00:14:36,050
but the other cell of the same list can be the one with the image and the rating and some other stuff.
142
00:14:36,120 -->
00:14:42,040
You can go to that small granular level if you want to.
143
00:14:42,120 -->
00:14:49,260
But the more you go there it becomes more complicated because now the server needs to return different types
144
00:14:50,050 -->
00:14:53,250
and you need to make sure that you conform to what server is returning.
145
00:14:54,070 -->
00:14:59,110
And what your HTML client can do, your web browser can do, what Android can do.
146
00:14:59,120 -->
00:15:05,025
Like you said, you want to take a really basic approach.
147
00:15:05,030 -->
00:15:09,210
I like the idea of doing the read-only stuff first and just hammering that out.
148
00:15:12,090 -->
00:15:15,010
If you’re going to do this today,
149
00:15:16,010 -->
00:15:19,190
would you choose UIKit? Would you choose Swift UI?
150
00:15:20,010 -->
00:15:26,100
What are the benefits or drawbacks of taking each approach in iOS development?
151
00:15:27,010 -->
00:15:33,010
I think you can use either UIKit or Swift UI. But if I had to do it I would choose Swift UI because
152
00:15:33,115 -->
00:15:42,040
the declarative nature of Swift UI just makes it much easier to create those very small one thing to do components.
153
00:15:42,110 -->
00:15:47,030
That's why I would always use or I would use pretty much Swift UI for these kind of things.
154
00:15:47,035 -->
00:15:48,185
Although it can be done with anything.
155
00:15:49,010 -->
00:15:55,180
And if you're using Swift UI you will get one step closer for web apps if you're using React
156
00:15:55,185 -->
00:15:58,000
because React with UI kind of like the same.
157
00:15:58,060 -->
00:16:02,090
And if you're using Android or you're using Flutter for Android then you're
158
00:16:02,100 -->
00:16:08,050
pretty much in the same gist of it because React, Flutter, and Swift UI,
159
00:16:08,055 -->
00:16:12,180
they're pretty much the same structure that they work together.
160
00:16:12,190 -->
00:16:15,170
I mean, not work together but the same thing declarative nature.
161
00:16:16,050 -->
00:16:22,000
It’s composable. What’s the thing in Kotlin for doing Reactive development?
162
00:16:22,050 -->
00:16:25,110
I forgot what it's called. Composable UI or something?
163
00:16:27,100 -->
00:16:30,165
- I think Jetpack.
- Jetpack. Jetpack Compose.
164
00:16:30,170 -->
00:16:36,090
Jetpack Compose you can use that which is similar to Swift UI and all of that stuff.
165
00:16:36,170 -->
00:16:42,160
Definitely all of them will be declarative nature. I think another thing which I forgot to mention is navigation.
166
00:16:43,030 -->
00:16:49,195
Because in Swift UI, navigation is one of those things that people don't like
167
00:16:49,200 -->
00:16:53,180
that they have to put the navigation embed in the navigation somewhere.
168
00:16:53,230 -->
00:16:59,190
So using the server-driven UI you can actually change or control the navigation from the server
169
00:16:59,230 -->
00:17:07,240
so you can say that, “When I click a button I don't want to go from A to B. Now I want to go to A to C."
170
00:17:08,060 -->
00:17:10,110
This particular view, A to C.
171
00:17:10,170 -->
00:17:14,140
And you can do that. You can even change the navigation type.
172
00:17:14,150 -->
00:17:20,245
Meaning, do I want to perform a push navigation, or do I want to perform a modal navigation, or a sheet navigation.
173
00:17:21,030 -->
00:17:27,090
So you can control. You have those things you can control from the server which is actually pretty cool.
174
00:17:28,030 -->
00:17:32,080
Yeah, I was going to ask about that. Because that's one of the biggest drawbacks
175
00:17:32,160 -->
00:17:36,190
I've seen with people is the lack of dynamic navigation in Swift UI.
176
00:17:36,240 -->
00:17:46,040
You haven't seen a lot of friction as far as that's concerned using Swift UI and server-driven UI for that?
178
00:17:47,220 -->
00:17:52,040
For Swift UI in general and not talking about the server-driven UI, yes.
179
00:17:52,100 -->
00:17:57,010
As you said there is no correct way of doing a navigation thing.
180
00:17:57,030 -->
00:18:01,260
It always comes in the way because there's no central place like Flutter or React
181
00:18:01,265 -->
00:18:03,250
that you can put all the navigation part.
182
00:18:04,170 -->
00:18:11,080
There are a couple of different ways you can do it in Swift UI if you just keep your components very much
183
00:18:11,190 -->
00:18:20,170
rudimentary or very basic. It always gives the parent the control to where to go or where to perform the navigation.
184
00:18:20,175 -->
00:18:26,235
You can do on those cases but the amount of code you have to type increases 10x whenever you have to do that.
185
00:18:27,050 -->
00:18:33,245
Now, with the server-driven UI, all the navigation, everything which we call actions are on the server
186
00:18:34,060 -->
00:18:39,255
and they are translated to navigation links and all that stuff which is already in Swift UI
187
00:18:40,020 -->
00:18:42,150
so we are able to change that from the server.
188
00:18:43,010 -->
00:18:47,220
That makes sense. One of the things I saw in your YouTube course preview
189
00:18:47,230 -->
00:18:53,160
was the use of type erasure and having to do any view.
190
00:18:53,170 -->
00:18:57,175
Was there a reason why you had to do that when it came to server-driven UI?
191
00:18:58,060 -->
00:19:05,205
Yeah, I had to use any view because I didn't know what view is it going to, or which component as we call it
192
00:19:05,210 -->
00:19:09,190
in server-driven language, which component or view is going to return.
193
00:19:10,070 -->
00:19:16,235
Because we had different kind of views like rating view, list view, grid view, and some other view.
194
00:19:17,010 -->
00:19:23,010
You can try to use view builder if you want to but that approach didn't work out over there.
195
00:19:23,130 -->
00:19:30,110
Okay. When I've done stuff with Combine I've always ended up having to do type erasure because
196
00:19:30,100 -->
00:19:36,050
if I start sticking with the actual type name, it's going to be a mess because of all the different generics.
197
00:19:37,120 -->
00:19:40,260
I think I understand where you're coming from when it came to Swift UI and server-driven.
198
00:19:40,265 -->
00:19:46,230
It’s like, yeah, you could specify some view and do it that way but now you have to like
199
00:19:47,030 -->
00:19:51,120
carry that type, and it's a pain in the neck. Yeah, okay, I get where you're coming from.
200
00:19:52,080 -->
00:19:59,210
What are some gotchas when it came to server-driven UI as you were developing with it?
201
00:20:00,010 -->
00:20:05,150
I think one of the things which I didn't solve or wasn't able to solve was the same thing that we mentioned.
202
00:20:05,155 -->
00:20:08,030
I mentioned with the binding part of it.
203
00:20:08,020 -->
00:20:15,090
Meaning, if one of your views takes in a hat binding expression which changes the binding
204
00:20:15,150 -->
00:20:18,210
which will reflect or trigger something in the parent.
205
00:20:19,020 -->
00:20:25,000
There's no correct way to pass binding because it's literally in the server-driven UI it's
206
00:20:25,060 -->
00:20:29,195
it's just a loop running and it's just rendering all the components without passing anything to anyone.
207
00:20:30,000 -->
00:20:33,060
So that was one of the main things that I wasn't able to figure out.
208
00:20:33,140 -->
00:20:38,020
And the other part which is very important is versioning.
209
00:20:38,110 -->
00:20:46,130
What will happen if you add controls or you change your JSON or the server changes
210
00:20:46,180 -->
00:20:53,010
or sends you a different JSON but the client is not supported.
211
00:20:53,050 -->
00:20:57,090
You have to think about those cases. Now, there are many ways that you can solve that.
212
00:20:58,160 -->
00:21:06,030
One of the best ways I think is the server will know what version the client is running.
213
00:21:06,160 -->
00:21:14,020
The client will only request that URL and the server will only give the client those components
214
00:21:14,025 -->
00:21:19,050
or controls that are okay and accepted for that particular client.
215
00:21:19,120 -->
00:21:20,180
- Okay.
- Yeah.
216
00:21:20,185 -->
00:21:22,070
Do you like...
217
00:21:22,190 -->
00:21:25,230
How do you set up a new component?
218
00:21:27,240 -->
00:21:32,240
Because you'd have to make sure everything is in sync with the app store and deployment on the server.
219
00:21:32,245 -->
00:21:37,250
How do you arrange that mechanic?
220
00:21:38,010 -->
00:21:43,220
Yeah. If you are creating a new component, let's say, I'm adding a new carousel component
221
00:21:44,040 -->
00:21:47,240
then I will physically have to deploy the app to the app store.
222
00:21:48,090 -->
00:21:54,160
Once the client downloads or updates to the new version, they will get that component
223
00:21:54,220 -->
00:21:59,100
and their version number will get updated from one to two or whatever.
224
00:21:59,120 -->
00:22:07,060
So that we know that this person is on version 2. We should give this person all the components which are supported.
225
00:22:08,120 -->
00:22:15,010
Okay, the other thing, I was thinking about this is like fail safely.
226
00:22:15,015 -->
00:22:18,030
If they have a component that you don't support just don't show it.
227
00:22:19,180 -->
00:22:26,180
That was kind of my thought too. Because you have to make sure, okay, I deployed on the server quickly.
228
00:22:26,210 -->
00:22:32,160
Hit the release button or release the version of the app before the component is like...
229
00:22:32,180 -->
00:22:36,060
Yeah, right, it's tricky for sure.
230
00:22:37,210 -->
00:22:44,070
We kind of covered this but were there gotchas on the server end that you recognized
231
00:22:44,075 -->
00:22:47,170
when it came to supporting something for multiple platforms?
232
00:22:49,010 -->
00:22:56,225
From the server side, I think the main thing was always been to design a very generic template.
233
00:22:57,210 -->
00:23:01,010
That was the main and the hardest part because it has to be approved
233
00:23:01,015 -->
00:23:03,245
by the iOS, Android, web team, all the team, the server team.
234
00:23:04,050 -->
00:23:13,130
and you've to come up with some sort of a URL as well as some sort of a template that you'll give to the client.
235
00:23:14,080 -->
00:23:20,260
Apart from that and apart from the versioning issues which can be solved on the server as well as on the client,
236
00:23:21,070 -->
00:23:28,110
the server becomes the easy part to implement in these cases since it’s a…
237
00:23:28,130 -->
00:23:33,230
Well, I guess another question which came was if you're returning the UI
238
00:23:33,235 -->
00:23:38,110
meaning which components you want to render as well as the data associated with those components,
239
00:23:38,115 -->
00:23:41,020
should we make two calls or should we make a single call?
240
00:23:41,080 -->
00:23:47,150
I ended up making one single call which will return you not only the components that you want to render
241
00:23:47,190 -->
00:23:51,050
but the data associated with those components already filled out.
242
00:23:52,080 -->
00:23:54,230
- Ah, yeah.
- Yeah.
243
00:23:55,180 -->
00:24:01,115
Well, it almost gets a little like what is the component and what is the data, right?
244
00:24:01,120 -->
00:24:05,225
You are like what's really the separation there as far as like...
245
00:24:06,220 -->
00:24:11,205
Well, I guess the question that I was going to ask is how do you make sure when you design your app
246
00:24:11,210 -->
00:24:17,130
on each platform that it's still not designed in too generic of a fashion?
247
00:24:17,140 -->
00:24:22,230
If you know what I mean, like, you want your server-driven UI to be agnostic enough
248
00:24:22,240 -->
00:24:26,210
to where whatever info it gives the client
249
00:24:27,230 -->
00:24:33,030
if it is iOS, maybe in some cases you want to toggle in the web, maybe you want a check box.
250
00:24:33,035 -->
00:24:40,010
Like it's being agnostic enough to where your design is still looking as it's supposed to
251
00:24:40,015 -->
00:24:42,200
as opposed to being way too generic.
252
00:24:43,020 -->
00:24:48,080
You have one of those iPhone apps where you're like, “Okay, yeah. They built this in React native
253
00:24:48,085 -->
00:24:52,230
without really thinking through how it's supposed to look on the iPhone and what are the best practices”, right?
254
00:24:53,060 -->
00:24:57,120
Yeah. I think that's, as you said, that's the one of the best things that I found about
255
00:24:57,160 -->
00:25:02,060
server-driven UI is that server is only returning you the JSON. And the client,
256
00:25:02,065 -->
00:25:04,220
meaning the React app or Flutter app or Android app.
257
00:25:05,020 -->
00:25:11,260
they're the ones building, consuming the JSON, and then deciding that, "I need to create a rating control."
258
00:25:11,265 -->
00:25:14,270
"I'll create it the way that I want to create it."
259
00:25:15,180 -->
00:25:17,140
So those components will be...
260
00:25:18,120 -->
00:25:23,070
native to the web platform, and Android platform. Whatever they're implementing.
261
00:25:23,130 -->
00:25:27,150
Yeah. And that's something you probably want to circle your design team into if you have one,
262
00:25:27,160 -->
00:25:33,140
“Hey, by the way we have this component for rating. How should it look on Android?
263
00:25:33,145 -->
00:25:35,190
How should it look in iOS? How should it look in the browser?"
264
00:25:35,200 -->
00:25:37,040
Yeah, absolutely.
265
00:25:37,190 -->
00:25:43,240
What other errors might you run into besides versioning issues that you should probably think about?
266
00:25:44,110 -->
00:25:48,260
I think one of the most common is what happens if...
267
00:25:49,130 -->
00:25:53,130
in no WI-FI situation or the server isn't responding correctly?
268
00:25:53,170 -->
00:25:56,050
Meaning, it's just down or being updated.
269
00:25:56,220 -->
00:26:05,020
In those cases, the fallback is only you can display some sort of a local template
270
00:26:05,050 -->
00:26:09,090
which is saying that a local view which is unable to connect to WI-FI
271
00:26:09,170 -->
00:26:11,220
or things like that because there's nothing you can do.
272
00:26:13,110 -->
00:26:20,150
Unless your app is caching that particular JSON or for some reason the actual template
273
00:26:20,180 -->
00:26:25,040
then you can revert back to that. But obviously it will be displaying some old information
274
00:26:25,110 -->
00:26:30,100
and may not be relevant in the case that you are implementing the app.
275
00:26:30,120 -->
00:26:32,000
You obviously don't want to display
276
00:26:32,220 -->
00:26:40,180
stale stocks or cryptocurrencies information or some sort of these time sensitive information.
277
00:26:41,020 -->
00:26:45,240
Right, right. Or at least have last updated app, right? Something that indicates.
278
00:26:48,000 -->
00:26:54,140
What made you want to… So I watched the really good course that people should definitely check out.
279
00:26:55,010 -->
00:26:58,145
One of the things is you developed it using Node and Express.
279
00:26:58,150 -->
00:27:04,020
What made you to make that decision and what were some interesting things that you found
280
00:27:04,025 -->
00:27:08,200
as you were developing using that for your server-driven UI?
281
00:27:09,030 -->
00:27:13,200
Yeah, great question. I mean, you can use any server platform that you want.
282
00:27:13,210 -->
00:27:18,140
You can use Vapor or Ruby on Rails, Django, whatever you want.
283
00:27:18,200 -->
00:27:22,100
I chose Node and Express because that's what I teach every day to my students.
284
00:27:22,105 -->
00:27:24,030
- I'm pretty familiar with that.
- Okay.
285
00:27:24,050 -->
00:27:30,100
I also chose Node and Express because it's a very mature framework
286
00:27:30,105 -->
00:27:34,010
as compared to, let’ say, Vapor. I mean Vapor, is great.
287
00:27:34,070 -->
00:27:40,140
But I would choose Node and Express over Vapor at this point because Vapor is still continuously changing
288
00:27:40,190 -->
00:27:46,210
which is a good thing but if you're implementing or you're creating your data, I mean the back end,
289
00:27:47,000 -->
00:27:53,140
you want something a little bit more not that fast-changing thing.
290
00:27:54,170 -->
00:28:01,120
But you can use Vapor if you want. I simply chose Node and Express because I teach it every single day.
291
00:28:01,150 -->
00:28:04,090
I'm familiar with it. It's very easy to deploy.
292
00:28:04,100 -->
00:28:09,010
Actually, you can write the old Node and Express app on glitch.com
293
00:28:09,050 -->
00:28:13,040
which is already deployed basically so that's a good thing.
294
00:28:13,120 -->
00:28:16,065
And one of the things which you may have already seen in the course
295
00:28:16,070 -->
00:28:20,070
is that I started with creating a very simple app using Node and Express,
296
00:28:20,110 -->
00:28:27,120
but then I quickly switched to just a local JSON file so that I can do iterations,
297
00:28:27,125 -->
00:28:34,220
multiple iterations much faster instead of consuming or doing those HTTP calls.
298
00:28:35,060 -->
00:28:37,140
One of the things I've been thinking about is…
299
00:28:37,220 -->
00:28:42,020
So I redesigned the Bright Digit website by the way pretty recently.
300
00:28:42,090 -->
00:28:46,180
People should definitely check it out. I designed it, I wrote in Publish.
301
00:28:47,090 -->
00:28:53,170
Sundell’s static site generator. And one of the things I've been thinking about is,
302
00:28:53,180 -->
00:29:00,100
what if I have it output just a JSON file and then I build an app that consumes that,
303
00:29:00,025 -->
00:29:06,130
and it is a Bright Digit app, right? So you can almost convert it from a
304
00:29:06,210 -->
00:29:12,170
website to an app just using this but without the dynamic web calls because it’s just a JSON file.
305
00:29:12,140 -->
00:29:16,190
That’s been in the back of my head as something to play around with as well.
306
00:29:19,080 -->
00:29:23,070
We talked a little bit about decoding. Was there anything else you wanted to mention?
307
00:29:23,200 -->
00:29:30,220
Sounds like you did more of a string any type and I mentioned associated enums.
308
00:29:31,000 -->
00:29:34,150
Anything else that you ran into when it came to decoding your JSON?
309
00:29:35,020 -->
00:29:40,000
No. I mean, that was a little bit of a hard part because when you're returning from the server
310
00:29:40,010 -->
00:29:45,110
your keys will be in string. We already know that or most of the cases. But the value can be anything.
311
00:29:45,160 -->
00:29:49,235
I could have used your technique with the associative types.
312
00:29:50,030 -->
00:29:58,000
I use like a creating any decodable type, or struct, or something and
313
00:29:58,040 -->
00:30:01,120
and you have to do a manual decoding process which was kind of painful
314
00:30:01,140 -->
00:30:07,020
but it worked out in the end just fine because it was able to decode anything you give it.
315
00:30:07,080 -->
00:30:12,200
It will decode it to a dictionary, and then from the dictionary I can convert it to any type I want.
316
00:30:13,190 -->
00:30:18,210
What are some ways that you would recommend approaching testing with this stuff
317
00:30:18,220 -->
00:30:23,030
both on the server side and on your individual client side?
318
00:30:24,170 -->
00:30:33,010
For the client side it's recommended that instead of starting with the server you start with a local JSON file
319
00:30:33,060 -->
00:30:38,190
so that you can come up with a nice template or generic template for your
320
00:30:38,200 -->
00:30:41,180
result that your JSON service is going to send you.
321
00:30:41,220 -->
00:30:45,090
So instead of implementing the service just come up with a template.
322
00:30:45,100 -->
00:30:48,140
See if it works. It will be obviously much faster because
323
00:30:48,150 -->
00:30:51,230
it's a local file as compared to HTTP requests to a server.
324
00:30:52,020 -->
00:30:56,000
And you will go through those iterations much quicker.
325
00:30:56,050 -->
00:31:02,030
Now, when you're comfortable with the first version of your JSON structure or whatever you're going to return
326
00:31:02,080 -->
00:31:09,170
then you can move on to the server part. And from the server part I think the only thing you have to
327
00:31:09,180 -->
00:31:16,265
apart from sending the right data and the right content like the components or structure of the components,
328
00:31:17,080 -->
00:31:26,050
you have to just make sure that the URL that you're using that makes sense for your server.
329
00:31:26,150 -->
00:31:30,240
And also you have to make sure that the versioning is correct and you're sending
330
00:31:31,040 -->
00:31:36,110
the correct components and the correct response for the client that is requesting.
331
00:31:36,120 -->
00:31:42,150
So if a client is version 1 don't send that client components that are only for version 5
332
00:31:42,190 -->
00:31:45,090
because that's not going to work. It's not going to show anything.
332
00:31:45,210 -->
00:31:46,240
Right, right.
333
00:31:47,110 -->
00:31:50,160
And then just make sure your app doesn't crash if it gets a component that doesn't work.
334
00:31:50,165 -->
00:31:52,260
- Oh yeah. Definitely.
- That's the last thing you want to deal with.
335
00:31:53,010 -->
00:31:54,050
Absolutely.
336
00:31:55,020 -->
00:31:59,120
I remember a while ago. I don't know if you remember this. I don't know which app it was.
337
00:31:59,125 -->
00:32:05,230
but somebody had put out a library that you can design the whole entire app on the server.
338
00:32:07,120 -->
00:32:12,120
I think they essentially had it like take down by Apple in the app store.
339
00:32:12,170 -->
00:32:15,140
What I remembered about that was
340
00:32:16,060 -->
00:32:22,190
they had it down to where the whole entire app could be designed on the server
341
00:32:22,200 -->
00:32:29,175
and all the app, the actual app code did was just render it out. And I think like
342
00:32:30,050 -->
00:32:37,220
a big difference between this is the app doesn't really change. It can't be just changed on the server.
343
00:32:38,030 -->
00:32:42,100
It's more or less the components are already pre-defined on the app
344
00:32:42,105 -->
00:32:48,070
as long as you're giving Apple the consistent experience you're pretty much okay.
345
00:32:48,075 -->
00:32:53,070
Is there any other app store gotchas you might want to worry about going with this approach?
346
00:32:53,090 -->
00:32:56,020
No. I think you nailed it. You're absolutely right because
347
00:32:57,100 -->
00:33:00,060
we're not really changing any logic or anything of the app.
348
00:33:00,065 -->
00:33:03,200
The logic is already built into the binary which is already on the app store.
349
00:33:03,240 -->
00:33:10,190
The only thing we're changing is we might be single instead of 3 rating stars. We might want to see 5 rating stars.
350
00:33:10,240 -->
00:33:15,010
Or we might be changing the ordering of the view or the navigation part.
351
00:33:15,030 -->
00:33:20,210
But anything the navigation is doing to the views and the ordering that already exists
352
00:33:20,215 -->
00:33:24,080
in the app binary which is already deployed and approved by Apple.
353
00:33:24,120 -->
00:33:30,100
So you should not have any problems with sending this to the app store.
354
00:33:31,100 -->
00:33:37,080
I mean, app store review process should not have any restrictions on these kind of things. I mean, we have
355
00:33:37,150 -->
00:33:40,220
Spotify, Uber, Airbnb, Flipkart, and so many different
356
00:33:40,225 -->
00:33:43,000
- Yeah, they are all doing that.
- companies doing that same thing.
357
00:33:44,000 -->
00:33:49,020
I don’t know. If you have an app where you have a log in you need to set up for your app store reviewer
358
00:33:49,080 -->
00:33:54,210
just make sure when they log in they have basically the same experience your typical customer would have.
359
00:33:54,215 -->
00:33:57,230
And I think you're good to go as far as the app store review is concerned.
360
00:34:00,080 -->
00:34:04,000
Before we close out a couple of questions I wanted to ask you. What are you working on right now?
361
00:34:04,100 -->
00:34:07,150
I'm working on a couple of things. I'm trying to finish out my book
362
00:34:07,155 -->
00:34:11,200
of how you can become a developer by attending coding boot camps.
363
00:34:11,205 -->
00:34:13,140
Uhm, it's....
364
00:34:15,050 -->
00:34:21,250
It's written from the angle of my 5 years of experience as teaching at coding boot camps and graduating 250+ students.
365
00:34:22,010 -->
00:34:28,010
But it's also for self-taught developers who can read this book and not attend the boot camp but just read the book
366
00:34:28,060 -->
00:34:31,100
and they will get a lot of tips and tricks of, you know,
367
00:34:32,150 -->
00:34:36,200
how to microtask or how to design different things.
368
00:34:36,205 -->
00:34:44,030
It's not a coding book per se but it's more of what goes behind the coding part of it.
369
00:34:45,210 -->
00:34:47,160
Do you have a link we could post in the show notes?
370
00:34:47,165 -->
00:34:50,090
I'm still writing so I’m still not done.
371
00:34:50,120 -->
00:34:51,090
- Yeah.
- Okay.
372
00:34:51,095 -->
00:34:53,045
No preview link or anything like that?
373
00:34:53,050 -->
00:34:54,240
Yeah. I don't have a preview link.
374
00:34:54,245 -->
00:34:59,230
And the other thing that I'm working on which hopefully should be done before WWDC
375
00:35:00,040 -->
00:35:06,200
is a new brand new course on Udemy for RealityKit and Augmented Reality using RealityKit.
376
00:35:06,205 -->
00:35:13,040
That is something that I'm working on slowly. Hopefully, that will be done before WWDC. But we'll see.
377
00:35:13,120 -->
00:35:20,230
I have a few ideas of why I've not done RealityKit or AR Kit and why I'm intimidated by it.
378
00:35:22,210 -->
00:35:29,030
To me it's, A, I have to write all this tree. I have to build out these models and then I have to
379
00:35:29,110 -->
00:35:31,200
get machine learning stuff involved.
380
00:35:32,030 -->
00:35:36,000
It seems really intimidating when it comes to those frameworks.
381
00:35:36,005 -->
00:35:39,160
What do you recommend for somebody who wants to get started on those?
382
00:35:41,060 -->
00:35:42,280
How they should approach it I guess?
383
00:35:43,150 -->
00:35:44,200
Uhm, so it's...
384
00:35:44,240 -->
00:35:50,080
I know that some people think that they to be a math genius or something. It doesn't.
385
00:35:50,090 -->
00:35:55,120
I mean, you don’t have to know a lot of math to begin with RealityKit or Augmented Reality.
386
00:35:55,180 -->
00:36:02,135
And for as you said about models, I don't know how to create any 3D models. That's a completely different skill.
387
00:36:02,150 -->
00:36:08,000
but I'm good in finding different models either from Sketchfab, or TurboSquid,
388
00:36:08,005 -->
00:36:11,030
or even Apple models which are available on Apple's website.
389
00:36:12,060 -->
00:36:16,140
I do already have courses on ARKit but that's obviously a little bit old now.
390
00:36:16,145 -->
00:36:20,090
I think it's like 3-4 years old and those I created. But uh...
391
00:36:21,000 -->
00:36:27,070
But RealityKit, if you want to start beginning, I mean start to learn about RealityKit,
392
00:36:27,110 -->
00:36:33,230
I would definitely recommend the books from Ray Wenderlich’s website to introduce RealityKit,
393
00:36:33,235 -->
00:36:38,130
or some just general YouTube videos on RealityKit, and obviously the WWDC
394
00:36:38,170 -->
00:36:40,200
which will introduce RealityKit part of it.
395
00:36:41,110 -->
00:36:47,060
But if you're thinking that it's too much math involved. I have to learn Calculus and all that stuff.
396
00:36:47,110 -->
00:36:53,080
It's not that. It's just instead of two axis now obviously there are three x, y, and z,
397
00:36:53,120 -->
00:37:00,110
and you just play around with those things. It's kind of fun, yeah, but not much math involved for most cases.
398
00:37:00,210 -->
00:37:04,090
- Alright. You're encouraging.
- Yes.
399
00:37:05,130 -->
00:37:09,050
So before we close out I want to chat a bit about WWDC.
400
00:37:10,000 -->
00:37:13,010
We'll start off with what do you expect is going to happen this year?
401
00:37:13,015 -->
00:37:15,100
As far as maybe what the big things are going to be?
402
00:37:17,120 -->
00:37:21,030
I usually don't expect. I mean, I know that it's going to be...
403
00:37:21,035 -->
00:37:25,040
My expectation and I think my wishes for WWDC are pretty much the same
404
00:37:25,090 -->
00:37:31,170
which is Swift UI improvements especially on the part of Map Kit because Map Kit is quite limited.
405
00:37:32,000 -->
00:37:38,150
Testing, a little bit more testing infrastructure for Swift UI even though you can test Swift UI views
406
00:37:38,155 -->
00:37:42,240
but maybe we want it to better support a little bit more.
407
00:37:43,040 -->
00:37:48,020
I know that there have been talks about some core data replacement frameworks online
408
00:37:48,025 -->
00:37:53,010
but I don't think that's going to build out. But something related to that called Swift Data or something.
409
00:37:53,090 -->
00:38:01,080
And one wish that I had for several years which is going on for at least 5 or 6 years
410
00:38:01,100 -->
00:38:07,020
is some sort of a server-side Swift framework from Apple so that other people who are
411
00:38:07,040 -->
00:38:13,240
not back-end developers they get a chance to experience a back-end and to create
412
00:38:14,050 -->
00:38:18,050
services and server-side pages or server-side APIs.
413
00:38:18,100 -->
00:38:22,150
Because once Apple pushes out something it gets more traction.
414
00:38:23,080 -->
00:38:24,090
What do you think like...
415
00:38:25,100 -->
00:38:29,120
I mean, Vapor is probably the most mature of the ones out there.
416
00:38:30,170 -->
00:38:37,010
What would be the benefit to Apple to doing a different one I guess since Vapor is already out there.
417
00:38:37,115 -->
00:38:42,120
But also they're not really even though they try to they're not really a server side company,
418
00:38:42,125 -->
00:38:44,040
you know what I mean, other than Cloud Kit.
419
00:38:45,120 -->
00:38:48,120
How could you see that scenario play out I guess?
420
00:38:48,125 -->
00:38:54,125
I think it will definitely help other people to use the server side framework from Apple
421
00:38:54,130 -->
00:38:57,150
because once Apple pushes out something, like they pushed out Combine,
422
00:38:57,200 -->
00:39:02,240
and now everybody's jumping switch from RxSwift to Combine and to functional programming.
423
00:39:03,020 -->
00:39:08,120
And now they're introducing async and await and all those things that they introduce so everyone is using that.
424
00:39:08,170 -->
00:39:13,090
But I think it will definitely help people get off the paid platforms
425
00:39:13,095 -->
00:39:17,100
or third-party platforms which may or may not exist in the future.
426
00:39:17,150 -->
00:39:19,210
So you're thinking they'd host something?
427
00:39:19,215 -->
00:39:21,230
- Yeah, yeah.
- Okay, okay.
428
00:39:21,240 -->
00:39:27,220
Once they develop it, I mean, the framework also like a Swift Air or something so that they can write...
429
00:39:27,230 -->
00:39:28,220
- Swift.
- I like that name.
430
00:39:28,240 -->
00:39:35,225
So they can write a server side back end in Swift using Apple framework
431
00:39:35,230 -->
00:39:40,200
and then they can deploy it on Apple or somewhere else if they want to.
432
00:39:41,010 -->
00:39:45,140
Yeah, almost like if they could make it easier. I mean, they don't even have to write their own framework.
433
00:39:45,145 -->
00:39:50,010
They could just be like, “This supports every Swift-based framework
434
00:39:50,070 -->
00:39:55,120
here's a library for deploying it on our servers or AWS and be good to go.”
435
00:39:55,180 -->
00:40:01,030
And they don't even have to write their own so there's such a server-side Swift community out there already.
436
00:40:01,070 -->
00:40:05,020
It's like here's a library for deploying whatever server-side Swift thing you have
437
00:40:06,050 -->
00:40:09,050
and you're good to go and that would be fantastic. Yeah, I agree.
438
00:40:09,060 -->
00:40:14,020
That would be really be cool. I mean, the thing to me that always is they've really tried to
439
00:40:14,030 -->
00:40:17,200
increase their revenue on services. And to me like
440
00:40:18,000 -->
00:40:21,250
if you're going to do services, it's not just about having major league baseball.
441
00:40:22,070 -->
00:40:27,220
But Amazon makes a ton of its money off of AWS. That's where their money is.
442
00:40:28,020 -->
00:40:31,050
And if you want to do services, that's where the money is at like
443
00:40:32,010 -->
00:40:37,250
hosting a server, like a more advanced Cloud Kit or deploying server-side Swift apps.
444
00:40:37,255 -->
00:40:40,110
- But, yeah, that would be fantastic. Yeah.
- Absolutely.
445
00:40:41,090 -->
00:40:46,210
So that's my small wish list and obviously improvements for Xcode so it can run
446
00:40:47,010 -->
00:40:51,250
multiple previews or export previews for multiple devices at the same time.
447
00:40:52,010 -->
00:40:53,125
- That would be definitely helpful.
- Yeah.
448
00:40:54,000 -->
00:40:55,090
Yeah, yeah. Totally.
449
00:40:55,130 -->
00:40:57,230
Anything else you wanted to mention before we close out?
450
00:40:58,040 -->
00:41:03,175
I think we covered pretty much a lot of stuff and hopefully it will give a little bit of guidance
451
00:41:03,180 -->
00:41:08,110
and ideas to people if they are interested in server-driven UI.
452
00:41:08,190 -->
00:41:11,070
And, yeah, I think that's great.
453
00:41:11,240 -->
00:41:14,000
Well, thank you so much, Mohammad for coming on the show.
454
00:41:14,005 -->
00:41:16,000
I really appreciate it. I’m really glad to have you on.
455
00:41:16,140 -->
00:41:18,030
Where can people find you online?
456
00:41:18,100 -->
00:41:22,280
I'm on Twitter. I’m very active on twitter so you can follow me @azamsharp.
457
00:41:24,020 -->
00:41:27,200
Awesome. Thank you so much. I really appreciate it.
458
00:41:29,000 -->
00:41:34,000
Yeah, people can find me on Twitter @leogdion. My company is Bright Digit.
459
00:41:34,010 -->
00:41:39,200
Please take some time to post a review on Apple podcast, Google, Spotify, wherever you're listening.
460
00:41:39,185 -->
00:41:42,070
If you're watching this on YouTube like and subscribe please
461
00:41:42,180 -->
00:41:47,010
and I look forward to talking to you again. Have a great day. Bye.
462
00:41:47,015 -->
00:41:48,160
You too. Bye. Thanks!
