I know how to build tools, backends and APIs and I think I'm good at it. I've also built some web apps but those web apps have been of the traditional type: multi page applications where 90-95% of the logic was server side. Every page was fully rendered on the server and augmented by jQuery, Bootstrap and the usual suspects. Ajax was used to communicate to the server when needed. Basically like web apps in the 2000s :-D
Recently, to learn something new, I've ported the JavaScript of one of such apps (in Rails) to ES6 using webpack but it's still a traditional app.
I have been tasked by a client to write the prototype of a new app (as a solo developer for now) and since the deadline is not a cut-throat I would like to set the foundation for something "more modern" and learn new things in the process, especially because my skills on the frontend are definitely not on par with my skills on the backend. Also the word prototype in company lingo, as you all know, means: ok it works, let's add a gazillion features yesterday.
The first prototype of this app will basically be a form where the user can input some data and upload some pictures. The output will be some JSON then processed by the server in a separate process, yet to be written, that has to do some other stuff with it (sorry if I'm being too generic).
In the medium-long term this functionality (the form) will be part of a, hopefully, giant dashboard + admin that reads data from multiple sources (APIs and a backend), has analytics in it (that's why dashboard) and has notifications and status updates so that the user can know what the heck is going on :-D
I'm telling you this because knowing the direction the app it will likely take it's useful even when you have to come up with a prototype.
If I didn't care about learning new things I would start "tomorrow" by designing the backend for the prototype, then firing up Rails or Flask with jQuery and a CSS framework and do the old multi page web app thing as usual.
But I do care so I'm asking for your help. I've read a bunch of stuff on the web today (here it's 4pm) but I'm more confused than before. I'll end up with some statements and questions to help you (or me?) understand:
First version is a form, goal is to make it become a giant dashboard & admin tool.
Can it be a SPA? Should it be a SPA? Can a dashboard/admin be a SPA? It's a private app so nobody cares about SEO. I've never written a SPA by myself (I've worked on one with Backbone.js back in the day but it feels like a thousand years ago).
Can it be a MPA? Should it be a MPA? Can a dashboard/admin be a MPA with Vue?
Mobile first (but has to work on the desktop) would be greatly appreciated by me and the future users I am sure
I would like to use Vue.js for the frontend
How can I decide how much logic is in the frontend or the backend? Who shall do the routing? Who shall do the rendering? Will the server basically be just an API?
I would like to design the web server as a support for the frontend, not the other way around (shout out to 37signals :D)
I will be the only dev for now (frontend and backend) and I would like to use either Ruby/Rails or Python/Flask for this project (mostly because I don't want to learn a new framework for server of this project).
Since I am an army of one keep in mind I can't spend 3 months learning React, Redux, TypeScript and Phoenix from scratch, let's be practical.
Am I going to die?
As you can see I'm a little confused and eager to learn.
Thank you!
Oldest comments (5)
I think you have the right line of thinking. In Rails world, you can go "API mode" but I'm not totally sure what the implications of that are.
I'd question whether you need to go "single page", it will depend on the internal navigation of the site. If it's a dashboard a user uses but it's separate from another part of the app, there's not necessarily a need to tie them together in the routing logic. They could be separate client-side apps.
Either way, one thing I'd check out is "app shell architecture" in relation to service-workers. Taking that into consideration early will help you make best use of modern browser APIs.
I didn't think about having multiple client apps (like one for the dashboard and one of the admin for example). It might also help avoid coupling in the architecture of the frontend
Thanks, the app shell architecture seems very promising!
Yeah, and presumably if you needed to unify them with client-side routing, it wouldn't be impossible to do so later. But if that's not a major burden, I'd think it could be avoided. That being said, Vue may make this easy enough to deal with that it wouldn't be worth decoupling. I'm not familiar with the details there, but from some adjacent experience I'd say you don't need to make one monolith app.
Hi!
I just came here to tell you guys that this thread was very inspiring for me. I like to explore new things but in the last couple of months, after reading several articles about progressive web apps, I was more confused than anything else about the concept.
When Ben Halpern mentioned the "app shell architecture", I felt it was a very good name to start an investigation. That was last thursday. So, I "googled" it and got to this example:
samdutton.github.io/ilt/pwa/introd...
Last friday, after reading and understanding this article, I refactored a web site used by my team and the results are great in terms of user experience.
I think this is due to the questions you made, and the tip given by Ben.
Thanks
Daniel! I ended up reading more or less the same thing on Google Web Devs Code Labs developers.google.com/web/fundamen...
Glad my questions sparked something :-)
I haven't still cooked up anything (I went down the service workers rabbit hole :D) but I'm almost ready to write!