Under the hood – the technology stack behind Sematime
Today we look at the technologies that we have used to build Sematime. If you are looking at landing a developer job with us, it’s time to take some notes. We are Java diehards; everything we have built is based on this great and timeless language. From our client facing web applications, administrative tools, our mobile application, REST API backend, we are unashamedly Duke’s biggest fans.
“You mean you use that old piece of juggernaut”, you ask. Hell yeah we do.
“But why, there are all these new languages and frameworks you can use these days?” We know but lets just say nothing beats an old and tested language with massive resources and support available anywhere you look. After all, a programming language is just a tool and every blacksmith has their favourite. Right?
Web application with Vaadin
Schools use our web application to manage parental engagement. It’s built using the Vaadin Framework – it’s a Java based web development framework that is based on the Google Web Toolkit. Heard of GWT?
Vaadin improves on GWT by providing a whole set of greatly built, good looking, modern and ready to use UI components. From textfields, buttons, sliders, dialogs, the grid, date pickers, charts etc. Here’s a list of all the UI components – https://demo.vaadin.com/sampler. These are provided out of the box with no additional tweaking needed. There are thousands of ‘Add-ons‘ – other non-standard UI components provided by the community.
Why all the fuss about UI components? Well, it’s all about reducing the development time and the developer manpower required to bake an idea into a market-ready product. When you have a small development team on a budget every coin and minute counts. Time spent hacking that PSD can now be spent creating the business logic and you do not need both backend and frontend developers – one will do.
The default Vaadin demo, isn’t it great?
Mobile app with Codename One
Heard of this framework? I wouldn’t be surprised if you haven’t. Before the iPhone and Android we used to write mobile phone apps using J2ME – The Java 2 Platform, Micro-Edition. Seasoned J2ME developers will remember LWUIT, the Lightweight User Interface Toolkit developed by Sun Microsystems to to enable easier J2ME user interface development.
Codename One was created by the Chen Fishben and Shai Almog, the guys behind LWUIT. According to Wikipedia, Codename One is
a cross device platform allowing you to write your code once in Java and have it work on all devices specifically: iPhone/iPad, Android, Blackberry, Windows Phone 7 & 8, J2ME devices, Windows Desktop, Mac OS, and Web. The biggest goals for the project are ease of use/RAD (rapid application development), deep integration with the native platform & native speed.
There are many reasons we love Codename One but their biggest selling point is the ability to maintain one codebase and use it to write mobile apps that can run on iOS, Android, Blackberry and Symbian based platforms. In fact, it’s the only framework that allows you to write iOS apps without a Mac. With a small development team on a budget it really makes a lot of sense to save on valuable development time and developer-manpower.
The secret behind this great framework is platform abstraction – they hide all the complexities of having to deal with the underlying operating systems instead fronting a single set of APIs that let you achieve the original goal of Java, write once and run anywhere. Using your favourite IDE tool, you can have an app running in minutes. Their simulator is unlike anything you have used before – lightweight and superfast to boot. It even lets you switch between phone models letting you see exactly how you app will look on an iPhone 7 or Blackberry Bold or even a HTC One. That’s not all, old school Java developers who hate to declaratively design their UIs with XML will find lots of solace in Codename One. All UI is done in Java giving you great flexibility and control. There’s even a graphical drag-and-drop based user interface designer if you are into that kind of thing.
When your app is done and needs testing on real devices, you need to submit a build request to Codename One servers. Usually, you specify the target platform for your app and the build server will send back a native app that can be installed on the phone. The build server is a set of computers maintained by Codename One, to which native build binaries are sent (notice that code is compiled on the client and sent to post-processing on the build servers), once a build passes it can be downloaded to the desktop or instantly to the device using a QR Code/link/email.
Among other niceties we love about Codename One is great developer support. Shai Almog, one of the co-founders, gotta be the most responsive and active person on StackOverlow. Post a question and you’ll be guaranteed of a response with examples almost within two hours. They also main a very active blog updated almost daily with great tidbits for developers. Java is renowned for great communities and Codename One is no different. The fact that it’s open source, the entire source code is available on GitHub by the way, means anyone can fork it and extend it’s functionality beyond that provide by the framework core APIs. Check out their extensions directory for community contributed libraries.
Our Android app is developed using this great framework and we even got featured in the blog. Not to shabby, is it?
REST API backend with Jersey
Our mobile app architecture is based on the client-server paradigm. Not much really happens on the mobile app, it’s only an interface to present that which has been processed by the web application. Such that when schools update exam grades, parents can access them on their smartphones using our app. Our API is also used by legacy school management systems to push student data to Sematime. So instead of uploading an Excel workbook with subject scores, the legacy system can push them to our servers automatically the minute they are processed.
As such, we needed to find a way for the clients to communicate with the server. We settled for a REST based API with JSON as the only data format supported. REST as architecture of building APIs is really good. Due to its statelessness, it’s really scalable and offers great performance with limited resources. It’s simplicity, uniformity and the fact that it’s based on the HTTP specification makes it language agnostic – meaning no matter what your preferred development, you will be off to a great start since almost all programming languages expose HTTP clients that absorb the burden of having to deal with the low-level communication stuff between different network interfaces.
While there possibly are many ways to build RESTful web services, we settled for Jersey. It is an open source, production quality, framework for developing RESTful Web Services in Java that provides support for JAX-RS APIs and serves as a JAX-RS (JSR 311 & JSR 339) reference implementation. Jersey framework is more than the JAX-RS Reference Implementation, it’s own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development.
Check out our API docs at our developers page.
Hosting with DigitalOcean
This post would not be complete without talking about who we host our applications with, would it? Most of our web applications and the API backend are hosted on DigitalOcean. IMHO they provide the best hosting services: reliability is great, 99.99% uptime at all times day or night and also very generous with their offering. With Ksh 4,000 per month, you get a production ready VPS with 4GB of RAM, 2 Core processor, 60GB SSD storage and 4TB for both ingress and egress data transfers. Having hosted with Amazon Web Services before, that’s a steal if you ask me.
Unlike with AWS, DigitalOcean provides a plain vanilla Linux based virtual private server. There is no AWS like console to help you deploy your apps and provision a MySQL database. Everything is done on the console. If you are coming from a Windows background, you might find it tough at first working with the Linux console but the guys at DigitalOcean have great tutorials that will quickly get you up and running within hours.
Conclusion – it’s all about getting the job done
We would have loved to talk about how incredible NodeJS is or how fantastic Redis and MemCached are. We would have loved to talked about just how screwed we got when we used language Z or framework Y. But really for us, it’s all about getting the job done. Our users, and by extension yours, don’t really give a hoot of all this bs – they just want shit that works and is damn good at solving their problems. Period.
Our advise, don’t just adopt some of these new shiny languages and frameworks because you want to look cool and sexy. Use something that you are already really good at and that helps you ship sooner because at the end of it all getting a market product fit should be your priority.
They say premature optimization is the root of all evil. Do not fix it if it’s not broken.