The worst problems you’ll find building an Isomorphic Application (pt. 1)
The time has come and using only Javascript for an entire application makes sense, but there is a few complications in this new path that you should be aware.
And if you don’t know what an Isomorphic Application is or you just think you know, read this first:
I’m building an isomorphic application with a huge challenge: short time, a small team and not everything I need ready. I feel like jumping from a cliff while I’m building my plane. So I decided to post about my discoveries that I couldn’t find them clear enough browsing my old friend Google. I don’t know how many posts I’m gonna do, so I hope all of them help you out with something. :)
In this part of this series, I’m going to talk about 2 main topics: choosing your stack and first research problems, the second one will be better detailed on part 2.
How we choose our stack
You have no idea important your stack is, because it envolves such things as your company culture or your team profile. It is not only “am I a SaaS or an e-commerce?”
If you choose to go through this way (I’m talking about an isomorphic application) you’re probably working on an innovative and conceptual new application to fit the better market and be modern, which is great, but did you think about attract the right developers for you?
We choose our stack considering things like:
- Performance;
- A SEO friendly application;
- Be attractive for developers;
- Community and stability of the chosen technologies;
Since we’re building an entire new e-commerce and we want to be innovative, attractive and fast, knowing what you’re doing is essential, so that’s why we had a lot of research time to do it.
Most developers want to build the fastest, but this being the main concern, they mostly don’t think about building an awesome experience. You should think about it.
Performance
It’s the “easy” part of everything. There isn’t a rule book. Since we’re using Javascript for everything, we just need to build it properly and we’ll have a good result with performance. But there is always a “but”.
For sure we depend on external variables like “How many data can we store on the client” or even “how fast will the API respond”, but we have alternatives to improve perceived performance.
In the Javascript side it is not about not use jQuery, it is not even parameter to it. The problem of jQuery actually is one piece that seats in front of the computer called “developer”. There are awesome and high performance tools built with jQuery, like Trello. You please stop with jQuery pre concepts.
You need to think about the first load, so the size of libraries matters a lot.
Don’t go npm installing every cool stuff that you see, you’ll fail miserably.
You need to think how those libraries together impact the processes, how they can easily manage long objects of data and etc.
Reverse engineering, testing, failing, testing again…. Do you wanna call yourself engineer? So do your engineer job.
A SEO friendly application
If you got the point, we’re building an e-commerce and we’re using only Javascript (yes, no template engine). That means we’d probably have a problems with search crawlers not “understanding” our website, but we knew there were some ways to do it: hacky ways and properly ways.
Once we got the Virtual DOM technology working, we did not depend on DOM, which means that we had more flexibility to insert our markup on the server if needed (and it is). If you never saw something like this, wait for it. :)
Be attractive for developers
Like I always say in events and meetups I go to, if there are no people, there is no event. It’s the same for companies and if we extend this phrase with one adjective:
If there are no brilliant people, there is no brilliant company.
Good developers and designers are motivated people who love to innovate and create things with awesome technologies. You need to think that awesome challenges are going to bring to your company awesome professionals, and they’ll build awesome stuff. It’s math, you don’t need to go that far to understand.
Technologies community and stability
I want to think that I really don’t need to talk a word about this topic, so please, keep in mind that your ego and your laziness must be removed with sudo and every kind of research must be done with caution.
Take some time to make sure all tools make sense for you and be happy. Stability is important to scalability, which you’ll love you from the past, in the future.
First Research Problems (Overview)
(Overview because details are going to be at part 2)
When you think “yes, probably somebody has already done and it is on Stack Overflow”, please stop. Maybe there is some nice content, but that secret sauce you need to your specific awesome product won’t be there. Here is a list of the searches we did which took a lot of time and effort from the team at this point:
- How to properly fetch information in both sides, server and client, with the same code;
- How to not fetch things on client when we already did on server;
- How to make sure that we gonna have HTML markup for crawlers to understand us;
- How to run ES6 full features on NodeJS;
- (spoiler alert) When you find how to run ES6 features on NodeJS, but it is not recommended for production because of its memory consumption, then what?
A lot of items, right?
Endings
It’s an introduction of a probably long and straight to the point series of articles. In the next parts, I’ll start to go deeper technically and conceptually on important points and decisions this challenge is taking.
I hope you liked it and if you did, please share, comment below anything that helps to improve the content or doubts. You can also reach me out on Twitter, I’ll be happy to answer and chat about Javascript or software design. :)
Part 2 is on air!
Detailed First Research Problems
Part 3 and 4 are coming :)
I’m already writing part 3 and 4 of this series and the rest will appear while the work is being done with this series.
- Part 3: Detailed First Research Problems (continuation);
- Part 4: Interface Design Patterns Importance.
Thanks!
And a special thanks to Rômulo Machado for reviewing this post. :)
