A bunch of ideas for developers working on large production apps.
Average App Anatomy
To reach the widest possible audience I will use ...
For further actions, you may consider blocking this person and/or reporting abuse
To this point, I'd actually advocate for going frameworkless and static on a landing page if possible. It's usually not a page with complex state/logic and performance and needling over pixels is what is important.
Server side rendering is actually simple if you strip away modern JS and write HTML.
Here is a great article on the tradeoffs:
developers.google.com/web/updates/...
Static Rendering is probably what you are referring to, server-side rendering implies some munging of data to render the final HTML and send it to the browser.
You are right and I wanted to suggest exactly what you commented. "Keep your landing simple and static (Server Side Rendered)". I was just carried away with my chosen stack and I incorrectly meant "Server Side Rendering your whole ReactJS app" by "Server Side Rendering". I will make a slight correction, thanks for this comment.
It's hard to maintain (react + react router + redux ) in the front and an APi in the backend.
For me, coding smart is use the old mvc pattern for the big shape and only react-like for some specialized components where we need a snapy UI
You know something, Iβve been thinking the same thing. After doing a few PWAs and realizing that it is indeed much more complicated, more parts, more potential problems, the old fashioned MVC is looking quite simple.
But it does depend on the situation though.
Yeah !, also the team's size should drive our stack, if we are small team, we should make it simple (simple to code, simple to test, simple to maintain).
A very nice video from Stephenson explaining very well this point youtube.com/watch?v=SWEts0rlezA
I am sorry to @Miklos Bertalan, all my comments are more related to the title of your port than the content Λ, btw great tips :)
Don't think I agree, the traditional web programming model (server side generated pages, no separation between backend and frontend) had a lot of drawbacks (look at the mess that you can easily get when you start to use AJAX, jQuery and so on).
The new "API + SPA" model (which is quickly becoming the norm or default when developing apps) has a much more simple and logical mental model, and a more sound architecture (by separating backend and frontend).
I do agree that with the API/SPA model you sometimes have more "boilerplate", but it's a programming model which 'scales', and which allows you to build more advanced apps/UIs, while keeping things structured and manageable.
What tools do you use for the MVC pattern? Just plain DOM and JS?
I use rails for the regular parts like loging and forms, react for isolated components when I need real-time or a intensive Ui.
To test everything, I use system test, to test my react components and it's interactions with rails.
I think it's a nice spot, This make me a lot more productive.
Fantastic article, some of the best and most practical advice I've read in a while, this is stuff that removes a lot of complexity and makes the simple things easy. Difficult stuff can be hard, simple things should be (and can be) easy but often we're wasting a lot of time by complicating the simple things.
I'm struggling with the security aspect of keeping a JWT in localStorage. that's potentially the same as keeping the whole user session in a non-http cookie, for any js script to read.
I see most apps keep their JWT there, yet it makes no sense π€ (At the same time I do see the benefits and sexiness of a static SPA)
This is a good point and it keeps coming back. There are some heated discussions about this and most articles are pretty one sided with a few slight half-truths against the other side.
I suggest you to read this article against local storage first.
I can't find a similarly good article for the pro-localstorage side but here are a few points to consider:
While LocalStorage is vulnerable against XSS, cookies are vulnerable aganst CSRF. Both are equally bad security issues and both can be mitigated (to some extent at least).
Server set httpOnly cookies are good for simple one server -> one client apps. When you need to open up your API you should not keep the session in cookies anymore. In these cases you should issues tokens to the clients and let them store them however they want to (DB on the server side or localStorage on client side). This is what oauth does as an example.
I am personally okay with both approaches and I try to secure things either way but I am not a security expert. It would be nice to hear the opinion of someone more experienced.
Keeping a JWT in localStorage doesn't just open you up to XSS, it also opens you up to session hijacking (a much more severe vulnerability imo). If someone/-thing grabs that token, then it has free access to your API for X amount of time. And since detecting that a 3rd party's or extension's script is reading something from your localStorage is impossible, then they can simply wait for the user to renew their session and attack again.
Way way way too complicated. Life is much simpler on the Web.
I would say that if you want to code smart, code with the real web-languages. I'm sorry but what you proposed is more coding hard than anything else, but this is only my honest opinion. I do understand the popularity of using such complex frameworks.
Still, great article!
What are "real web languages", PHP, Python, "anything but" Javascript?
In my experience, once you have a good base setup (see the tips in this article) building an app with the API + SPA model (e.g. with React) can be smooth and simple.
As soon as you require a bit more interactivity on the frontend and a more advanced UI then the 'old' model with server side generated pages, AJAX and jQuery quickly becomes cumbersome.
Great article, good advices. Bookmarked.
I am realllly advocating hard for "Tip #4: Init the App Properly"
Very nicely written, straight to the point, and solid advises. These advises hold regardless of framework
totally true. I'm going to check this boxes now on our vue app :)
Kudos! Really great artice
Nice infos, it also carries over to the other frameworks of course. π