So after spending some time with Meteor, I found that this is probably the best isomorphic data-centric framework to build web applications.
I am currently trying to build an HTML5 mobile application for Kids (Under 5 Years), the content of the application should get updated as the child progresses solving and interacting with the available activities. (So new activities should be downloaded at runtime of the application).
Mobile support of Meteor is good. Meteor + Cordova can serve my purpose.
But what I am confused about is:
Is Meteor is the best framework for my use case, where the application is mostly static. No state to be maintained across. (Only the number of levels crossed by the user has to be synced.)
But Application need something like Hot Code Push, (Don't know how to maintain that differently for each account)
If not, then what is the preferred tech-stack to build HTML5 mobile applications/games where it is required to push levels or new activities at runtime and that too differently for different users/clients. (Some might be the premium subscribed users getting extra level/activities on monthly basis.)
Related
SUMMARY: How to handle navigation, history and deep-linking in a PWA without using a heavy JS Framework ?
While leading a team to convert an existing shopping site form Angular 1 SPA to a Multi Page App (MPA) PWA I am stuck with some of the design decisions where I need little help as PWA is a fairly new concept (for me & my team).
My understanding so far is that we can totally avoid any framework and go with plain old javascript and service workers and split the SPA into MPA hence adding the benefit of splitting up resources needed on each page and not having to download a huge js file needed for the SPA to work.
The point where we are stuck is the ability to handle routing and deep linking with browser history API so that every part of a page has a unique URL and can be bookmarked.
We can surely manage that using fetch calls, updating only parts of the page with JS and pushing the browser state to history, but that seems like a lot of work and we should not be doing this in 2018.
Is there already some approach/library/pattern in the wild that has addressed this issue?
We looked into using react-router(using in other apps) or aurelia (small size) or polymer [sorry angular, you died under your own weight] but that seems like killing the very basic idea of PWA by adding a lot of code just to handle navigation.
Any thoughts?
Note: In case it is relevant, 90% of the app's target audience is on a slow network(~3G).
With you concern, I would like to break it down to three parts to discuss:
1."The point where we are stuck is the ability to handle routing and deep linking with browser history API so that every part of a page has a unique URL and can be bookmarked." - SSR support
If you want to build a website properly (saying converting from your SPA), with SEO support, social media sharing features, you will need to do some extra work for SSR (Server-side rendering) and generate static web pages. If you use React framework, you can look at:
Next.js (Great for most of applications need SSR)
Gatsby (Great for static websites like blogs, news etc)
React Helmet (You may need this library if your project starts from create-react-app or some boilerplate without SSR)
2."My understanding so far is that we can totally avoid any framework and go with plain old javascript and service workers and split the SPA into MPA hence adding the benefit of splitting up resources needed on each page and not having to download a huge js file needed for the SPA to work." - PWA and framework options.
You don't need any framework if PWA is the goal you are looking for. You can have multiple services workers managing different parts / modules of your website with different scopes (for example, '/users/' and '/products/' pages). But you need to do this carefully as my experience to debug multiple service workers is a nightmare.
And cache the app shell (bundle, css, images etc) of each part separately. Then, you can choose IndexDB to manage the data from your API and create proper indexes.
Google Workbox is also a great tool for PWA with a lot of features and can save you tons of time config your service worker.
"Note: In case it is relevant, 90% of the app's target audience is on a slow network(~3G)." - Caching strategy
In this case, you may need to consider your caching strategy before designing PWA. I would suggest to go with "Cache first, then network". So your users will at least have something to look at even the network is slow, under Lie-fi or offline.
Here is a great article from Jake Archibald: https://jakearchibald.com/2014/offline-cookbook/ with different caching strategies.
If the primary requirement is the ability to have deep link to every section of the app, to the extend that everything is bookmark-able, Aurelia router with its child router makes it very bookmarking friendly. For the concerns of slow network requirement, probably after the first download, it's should be like #MattYao stated already.
I'll be starting a project, and due to reasons I'd like to use angular.
However I know that soon after we start the web app we'll also start a mobile app in React Native. Over this I have no control (thus no reason to suggest Native Script).
Setting personal preferences of developers aside, are there any reasons why we should consider React for the web too?
Yes, there are many reasons to build both web and native targets with React:
Both use JavaScript and JSX so you have less technical overhead.
Both follow the same design patterns, so you have less technical overhead.
If you plan for it, you can reuse logic. This can save a significant amount of time and improve parity between web and mobile apps.
There are already a bunch of great resources out there on building applications that use ReactJS and React Native together, providing direction and momentum.
Writing micro-services on back-end is not that much confusing, specially if we are building api endpoints. We can write separate project for users management, separate project for reporting, ..., and combine all their endpoint with AWS gateway api, or for smaller one acomplish this with nginx reverse proxy to provide a integrated api service.
The way I am suggesting the team for writing back-end is something like that:
localhost:8001/list <- reverse proxy to -> apiproxy.com/users/list
localhost:8003/transaction <- reverse proxy to -> apiproxy.com/transactions/create
So it seems simple, we write our projects by category in separate repos, and each team/person can work individualy on it. But here goes my question:
" How can we implement a solution, that a server rendered React app ( Or, angular, Vue ) can render, and developed with separate repositories, but in build time, they merge into each other, and their routing works well."
So, in this senario, each repository must be able to bootstrap independetly. The aim is not create a new framework.
Does anyone has any kind of suggestion?
Canopy Tax, a tech startup based in Utah that builds solutions for tax professionals, faced a similar situation about 2 years ago. They wanted to be able to implement some sort of microservice architecture in the front end, and guess what, they succeeded. The solution is not perfect yet, there's a lot of trade offs, but the objective is met and they are using this in production with their customers. I have seen it in action at some meet ups they have hosted.
Canopy Tax open sourced their framework last year, it is called Sofe. Here it is the link to the github project. Their solution, is used in production and is here to stay for a long time. They recently raised another 20 million in VC this year.
This sofe framework is what they call a Meta-framework. It is basically a main router that decides where to dispatch your routes. Then it dispatches to an angular, ember, react, angular2 app. And it gets even better, in the same page you can have pieces built in react, pieces in angular, etc. You get the idea. This allowed them to scale faster, get more talent as well as they are no longer limited to just one framework. And they can deploy anytime and their teams (squads) don't depend on each other as those pieces of the app are independent applications, like microservices in the front end.
It is still fairly new but definitively worth a look. I recently talked with them at a meet up and some other companies are using this as well in production. They also have an inspector tool an other tools that show you what framework that piece of the web app you select belongs to (e.g. react, angular, etc). Here it is the live demo of sofe in action.
Click on framework inspector there, then turn it on. It will show you.
There's trade offs on this approach, one is that this is not supported yet for mobile. It works great for their product but they are working on solutions for that as well.
Disclaimer: I do not work at Canopy Tax, I have never worked there and I do not have any relation with the company. I just like Sofe and what they are doing with the project.
I'm making a simple gaming platform. It's supposed to be used only on (W)LAN. One of the devices is running a node.js server, and client devices can be computers, smart phones or tablets. I'm planning to handle all the client-server communication using socket.io, as that makes it possible to have almost real-time connection and to have sessions without having to manage user accounts.
When the user joins a system on a browser, the interactioin goes like this: Starting view ---> game selection view ---> join/create game view ---> game lobby --> actual game.
The question is, what would be a good approach for changing these views? I've thought about some possibilities:
I could load a partial web page (html-document) when a page is changed
I could load one large html-document when joining the system and show/hide divs on a page change
I could use some more complex framework
Which approach would be best, considering that the application will be used on mobile phones and therefore memory usage and battery life are important factors?
I would use Backbone.js Views. It's lightweight, and you can use it without using any other component from Backbone.
So I am a web (Rails) developer, and I would like to create an iPad application for my site. The web application heavily relys on javascript libraries that are built specifically to interact with users in a unique manner.
Now I would like to transform that same interaction to my iPad application. I need a way to reuse my js files since re-coding the libraries will take forever. There are three options that I might follow:
1- Using Rhodes: built on ruby and inspired from rails.
2- PhoneGap: which is basically a web browser inside an app, so I presume that including js files would be possible.
3- xCode: which will take lot of time for me to learn and implement.
My questions are:
1- Can I import my js files in the rhodes project?
2- Which is the best to implement this?
3- Is there any other options that I should be looking at?
Any hints and pointers will be greatly appreciated,
Thanks a lot everybody
As i am not aware of the app you are developing & its design, Two approaches i see here as it is Rails,
Mobile Web
The existing web app shall be customized to mobile web (iPad & most
of the tablet in fact).
Create controllers specific to mobile/tablet. this shall connect to views created specific to mobile/tablet.
Detect the device/platform when HTTP request is posted and re-direct to specific views you have created.
Good thing is your JS is always the same(will need minor modifications thou) and dev time reduced significantly without learning new stuffs.
PhoneGap
You can pull up all the JS you have written and build some html/css integrate everything and build the project inside a phonegap template for iOS and create a on-device app and distribute. but the JS will undergo some changes here too.
But this will no way be different than mobile web and this comes other overheads like CORS and build/release, updates management & app stores etc.
Native APP
As you said, you got to learn iOS development (objC). you can create RESTful services in your rails end and expose them to the iOS app.
Rhodes i am not very sure, its little tricky and it depends on your existing web app too. try it before deploying.