Spatis: The what?
January 15, 2020
As I mentioned in my previous post, I don’t exactly know how Spatis will be designed. I can start off by listing down all the parts that will (probably) make up Spatis. Before that, however, what is it that Spatis will do? Without a ‘what’, ‘how’ is somewhat immaterial when building things, and I somewhat conveniently left that in the introductory post.
So, ‘what’ will Spatis be and do? Overall, Spatis is a library that will assist fellow web developers to build simple web applications. The emphasis is on the term ‘simple’, because ensuring that Spatis can build the next Twitter is definitely not the goal here.
How is Spatis different from other server libraries. This is covered a bit more in the introductory post, but essentially Spatis will bridge the front-end back-end gap when building modern Single Page Applications. The question it’s trying to address is: Why do I need an API server and a front-end bundle when making single page applications, can’t I do both with the same code?
The above explanation is still very high-level. Let’s dive a bit more into the practical requirements for the proof of concept:
The Web Server
- should be serve fully rendered HTML pages when a supported URL is visited
- should not discriminate between front-end and back-end code. All code written should just work on either end of the picture.
- should be straightforward to use, no wizards etc. Import and build.
- should value convention over configuration
- once loaded, all routing will be done SPA style, no full HTML requests to be made
This is still somewhat raw, I think I’ll revise this more as we proceed with the development, but even more important than what’s on the list above, is what’s not on the list.
When starting off with projects like this, when we don’t know what to build fully, it’s easy to get sucked into a grander plan; one with all the bells and whistles. As engineers, we keep thinking about things we are building and the more we think about exciting projects with potential, the more we tend to add to them. Having a solid list of what to build is important when starting out. Especially so, when you don’t have product managers, business, and other stakeholders watching your every move. Restraint and simplicity are a lone engineer’s best friend.