starting the “remote-ui” project
let’s make all the view’s logic combined on serverside.
.. but why? ..
in the world of production service development, we face some awful concept called cross platform.
in the industry world. it is pretty common to use one of the stacks below
- native 2 + web 1+ server n (most common)
- react native + react + server n (airbnb style)
- flutter + web 1 + server n (google style)
- flutter + flutter web + serverless ? (some gangstas)
for app, we commonly choose between from native app (each android & ios), react native, and flutter. (i’m not including xamarin/ionic/etc..)
for web. react / vue / svelte. (i’m not including angular/etc..)
for server, the framework doesn’t matter. it’s about language, database and stuff. I personally use django (py) & express (js/ts). yes, serverless architectures are hot, and it will change alot. still i don’t believe the enterprises will go with serverless. not because it is young and new, just because it’s harder and takes more effort to sustain by the project grows. (in that reason, i’m excluding serverless too.)
now theses are narrowed down frameworks /languages that we industry needs for there cross platform services.
- flutter
- react native
- android native
- ios native
- react
- vue
- svelte
- and the server (what ever you use)
specific in app production. I personally think flutter will take over the world. and i am very happy with launching services using flutter. Just 3~5 years ago, there was really no viable options to choose via what you will make your app. you should have sticked with ios/android native. not only we had to create 2 exact same functioning apps like a dumb, it’s pure pain when comes to releasing mobile applications. and the development itself was not so fast.
I’m defining the first problem. (in native scenario) same functioning product, 2 separated resources (equals money).
let’s talk about web. in year of 2020. web’s tech market is now settled. you have only 2 to 3 options to choose, still same language base, instant & easy releasing, and so far. i dont think choosing between react & vue will make huge difference on your product. it will exactly be the same.
the problem remains are web’s chronic problem is (personally saying) the architecture it self, not oop friendly not really intuitive for beginners. for example. you have to make dialog under the page and toggle the state to show it? doesn’t really makes sense to non-web-developers. and sooo much options you can choose which makes things flexible. also mean hard to organize.
anyhow still the main problem here is there surely are alot feature sharing between web & app. in case of airbnb they reuse there code up to 80% with react-native & react. (which sounds easy, but not.)
others just make web-apps and port is nicely. “notion.so” for example. (which is not easy for optimization, but still a good choice)
lots of case requires instant updates, dynamic content loading. and for the QA’s perspective they have to double check if there native app & web works the same way as they planned (pure pain)
🥳
remote-ui to the rescue. server provided view data, fully centralized logic containers.
remote-ui provides interface for server to provide data for frontend, further it could just give the layout’s data.
e.g.
// server (simplyfied express-like syntax)
route('page/main', (req, res)=>{
res.json(
{
"layout": "layout-1-1-2",
"view": {
"title": {"variant": "default", "text": "welcome to main page!!"},
"main-button": {
"action": {"type": "push-route", "data": {"route" : "second/page/21"}} } } } )})
what if the server can decide the client what to display, and decide what the button will do? still you will have to work with the view, but with that pre-defined view the server can do so much dynamic things, and all the logic can be contained to the server.
i one word. api is not for giving the data itself. the api will use the data internally, and give the data how and what the client should draw.
the project has started from Aprl 2020, firstly supporting flutter, express, and vuejs
the code can be found below.