I’ve got a production Meteor web app that I want to create a mobile version of. I plan on moving away from MeteorJS soon so I want to decouple the mobile app from Meteor from the start. And I also do not want to complicate my frontend code that much more to add a mobile version to the pre-existing web-interface-only Meteor app I’ve got.
Meteor has made this kinda thing really hard, like a gated community or a walled garden. I would like to create my app using Ionic, but I do not want to change my server code too much to support it. Or I am open to other recommendations apart from Ionic, all I need is fast development speed.
Not to be rude, but I think Meteor has made this type of thing really easy. Unless you require advanced cordova functionality, you can pretty much maintain an isomorphic codebase and port to ios and android without too much hassle.
If you want to use two different view layers (e.g., bootstrap for web and ionic for mobile) then that’s going to take work, regardless of the other layers in your app.
Also, if you’re planning on moving away from meteor, maybe it would behoove you to post this in the respective forums that you’re planning to move to.
If all you need is fast development speed, why would you move away from meteor?
I do need to use two different view layers, and I would appreciate it if you could point me to some resource about how to do that with Meteor.
I have several reasons for moving away from Meteor. I have been using Meteor ever since it was not even at 0.5, and I love Meteor, but for this particular app it is time to move on. I need to support more than 1000 concurrent users for one. Also, with Meteor, I NEED a Meteor client for whatever platform I’m developing for, just having HTTP or websockets will not suffice. This hinders development speed too. Scaling is my main reason behind moving, and it will be done in phases.
Again, would appreciate resources for supporting multiple view layers and UIs from a single Meteor codebase, but do not want to tie down my mobile app to Meteor too tightly, as I need to support more concurrent users than Meteor can handle.
Again, I think your project needs are inherently conflicting.
If your plan is to move away from Meteor, then why are you seeking resources for adding an additional view layer to a Meteor codebase? If you’re using mongo, why not just start with ionic on a mean stack for your mobile solution?
Would that be doable though? I have a Mongo DB database for Meteor of course. Should I just wrap that up for mobile using say Feathers? As that is what I plan to move the web app to as well.
And I know I sound a little frustrated, but I REALLY do appreciate the advice vigorwebsolutions.
It all depends on your use case, but if you are going full throttle on mobile, I’d look at something like http://blog.ionic.io/one-mean-ionic-2-todo-app-on-heroku-part-1/ as a point of reference. Whether you use feathers or not probably just depends on what you’re trying to do. RN could be an option, too. Would probably depend on your team/budget/etc.
You could get by with something as simple as a basic mean stack with an express api?
Honestly, I’d say there are just too many unanswered questions/variables for someone to say use a combination of X,Y,Z. I’d spend some time prototyping a few views/data pieces and see what works.
If you want to move away from Meteor (why?) then you have to start from scratch and will have an uphill battle to have an isomorphic code base. The right away in my humble opinion is to make your app responsive, then you are essentially done.
Is the UI different because DOM is different or because CSS is different. If you can leverage same HTML, you can simply inject your CSS at startup. We do this for our apps to as different platforms have sometimes different functionalities.
I usually resolve such issues at the requirements level