Mashoom 7 Release Notes

Mashoom has grown up a lot over the years. It's gone from a hobby project into a full blown business solutions platform. In of itself that is an achievement, but the cracks were starting to show.

We have constantly upgraded old code to ensure we don't get stuck in the past but eventually you reach the buffers of the base architecture the project was started with. Normally this is the beginning of the end for a project / product, albeit the decline can continue for decades.

Very rarely does an existing product get it's technological foundations replaced. Even rarer for this to be done with full backwards compatibility. Mashoom 7 is just that.

TLDR; What Can I See Now?

This release is mostly about creating new foundations to build on. However, there are some nice things for our users right now:

• The login page has been redesigned. Quicker to use, remembers your details and most importantly, the awful "squiggly text" captcha has been removed for a "pick a picture" one.
• If your session expires, you will see a login screen you can use to login without losing your place.
• A new menu, featuring a better layout, proper mobile support and better support for custom styling.
• In general your session should be much more reliable; less (if not no) unexpected logouts and infinite refreshing.
• Greatly improved loading times, especially on subsequent visits.

A Giant Leap In Technology

Mashoom up to this point has been made up of HTML pages, generated by PHP, with JQuery "soup" to support it. We were a single page app, which was very impressive 5 years ago. However the web world has moved on hugely in the past decade, chiefly via the advent of client side frameworks.

Think of client side frameworks as a full computer program (or "app") that you download into your browser. All the text, images, styling etc is bundled together much like you would expect in a native app on your phone or computer, and it's the same for everyone. This app then wakes up and fetches the data and content it needs from the servers.

This is separated from an "API" or "Application Program Interface", which is a fancy term for "something you connect to to give you data". This means you have two separate code bases, one to create a user interface, the other to output data and make changes. This separation is really useful.

Mashoom, going forward, is now a React app, connecting via Relay to a GraphQL API. This is the same software stack that Facebook uses, although I must stress we are nothing to do with them and we can use these tools for free and without any agreement; they are open source.

What does this mean on a practical basis? Much more clever, data rich and performant user interfaces. We can also develop new products at an even faster rate, and use external components so that we don't have to write everything from scratch.

Take the inputs on the login screen for example; you've probably seen them before! These are from a very common open-source library called MaterialUI, created by Google. We can tap into these libraries, and any others, to bring our users the very best experiences possible.

New Infrastructure

Web infrastructure, and it's accessibility, has also changed dramatically in the past decade. Mashoom hasn't been making the most of these advances as we simply haven't been in the right place. Not to mention, changing infrastructure setup for a live app is not for the faint hearted. But we've done it.

Mashoom's app is now deployed "serverlessly"; we no longer maintain a server to provide the app. That is because everyone gets the same app, only the data is different per person. That means we can have a hard-drive in the cloud and cache these files in something called a "Content Distribution Network" or CDN.

A CDN means that instead of connecting to Mashoom's servers at a single location, you can connect to a server that's closest to you. This has benefits two fold; you need a huge amount of traffic to overwhelm Mashoom, and loading times are dramatically reduced.

We have also placed our API behind a CDN. The reason being that another advantage of a CDN is allowing advanced fire-walling tools to be implemented, alongside many other clever features.

A Brand New Framework

Most APIs are written to the "REST" standard. However, Mashoom has implemented a much newer standard which is being rapidly adopted; GraphQL. Without deep diving into what this is, it allows an infinite number of different types of request to be made. Think of REST like ordering from a menu and GraphQL as explaining the recipe you want making given the ingredients available.

A GraphQL API throws up a range of challenges and as of yet the tooling for how to build one is still developing. Mashoom already has a wealth of home grown technologies that were starting to form a framework, so the opportunity has been taken to formalize into a complete framework.

This means we can bake in the same rock hard security and ease of development that Mashoom currently has, and improve upon it given that now the only thing we have to worry about is data; not building user interfaces.

Part of this framework also makes it much, much simpler to create "asynchronous" tasks. The short is that this means we can easily offload some large processes and provide better feedback on processing progress etc; all boiling down to a better user experience and confidence to write more powerful operations.

End to End Deployment Process

Deploying a complex web application and API is difficult. Many elements can be automated but to bring all the elements together into a single command has taken years of experience to work out, then the time to finally write everything required.

A single command can now be run that securely builds, upload and deploys Mashoom's app and APIs.

There are two big benefits; far less chance for human error and a much faster / easier process. This, on a very human level, means we can get fixes and releases out faster as it simply reduces the friction of doing so.

An API Release

One glaring omission up to this point is Mashoom having no formal API. This basically meant people couldn't connect with us programmatically, so no scope for people to build extensions or partnerships and our customers couldn't connect their own tooling / automations as required.

GraphQL allows us not only to provide an API, but provide one that is very, very flexible. We can also provide a "playground", so anyone with a basic level of understanding can explore it, read all the documentation and test it using their actual data.

One thing we are noticing is some businesses have grown used to being able to connect to their internal databases in order to do a quick bit of analytics or to automate a process. This is a barrier when moving to the cloud. We hope this will plug the gap, by providing your data back in whatever way you need.

We still need to work how to present this API, and a few other details. So it's not available publicly quite yet, but expect to hear from us soon.

The Future; Native Apps

This is connected to the above; we are a big step closer to being able to write native apps.

We are not running towards this, chiefly because our web app is obviously available on anything where you can use a deployed web app. However, there are a few applications, for instance form filling, where a native app would be very useful.

So whilst it isn't on our road map right now, we are in the best position possible should a need and use case arise.