As a start-up with an often volatile cash-flow, Callstack provided a level of understanding that other organizations may not have done, allowing us to reduce developers when necessary and accommodating a few of our tighter moments. I would have no hesitation in recommending Callstack to others, to provide a flexible solution to an existing workforce or on a longer-term basis as part of a remote team.
<cyan>A free homework and teaching platform<cyan> for primary and secondary schools in the UK
edi is a free homework and teaching platform for primary and secondary schools in the UK, targeting teachers, students and their parents. It helps teachers plan their lessons, yearly schedule, and manage their classes, while for students and parents it provides rich insights about pupils progress and upcoming tasks.
<cyan>Scalable platform<cyan> with plenty of components
Finally, the app had plenty of perceptible, interactive components. One good example of it, could be teachers Scheme of Work planner, where one could view and interact with schedule for the whole year, dragging and dropping subjects wherever needed, expand and shrinking them, changing content of each, and all this wrapped within eye pleasing design and seamless animations.
Another thing to consider, was creation of consistent styles. Eedi is visually a very rich and engaging app, and all styles had to be consistent both in core web application, other marketing pages, and yet again, we had to consider mobile application coming in the near future. Solution to keep it consistent was really necessary.
Building an app from scratch, we had to think about future of the whole platform as well. While there was an existing endpoint, we had to figure out how to scale it properly, and prepare to handle requests of different data from different installments. We also had to think about upcoming mobile application, and best fitting solution for it as well.
Going custom <cyan>with everything<cyan>
As mentioned before, we had an existing backend service ready, but we had to consider the new requirements that were presented - a lot of new custom endpoints with custom logic, managing state of requests and responses, offline mode capabilities, and much more.
One solution, would be to add those endpoints to the old API, and prepare it for upcoming challenges, another one - built one from scratch, bearing in mind all the requirements.
Besides dealing with the API design we also had to figure out the best way to unify components and their styles throughout all the projects. The best solution that came to our minds, was creating separate GitHub repository with shared components, and then importing those whenever necessary. Creating somewhat a library with all of the building blocks that combined together would bring a beautiful visual experience for the users.
As for the UX part we had two choices - either use one of the existing solutions or to come up with our own custom one. We decided to approach each interactive component separately and create bespoke one wherever the existing solutions couldn’t help to solve the problems we were facing.
<cyan>GraphQL service<cyan> as a middleware
The best fitting solution for our backend issues was to use GraphQL service as a middleware between our app and an existing API. GraphQL schema is very easy to scale, it minimizes outcoming network traffic, prevents over- or under-fetching of data, and finally caches fetched resources for future which prevents duplication of request and enables offline mode usage of application. Disadvantage of such solution was the fact, that we had to create this service from scratch, and provide additional resources for this purpose.
To unify the designs we worked very closely with the design team and after many iterations we created a bespoke Design Language System - separate npm package that could be imported from every project from Eedi organisation and used independently by anyone.
We have created our DLS with `styled-components`, we have also used React Storybook - development environment for UI components. It not only allowed us to browse a component library, view the different states of each component, and interactively develop and test them, but also helped the designers while working on the new features.
The great thing about the DLS was that once the changes were made in the library, they were also automatically updated across all of the applications that were using it.
To create the timeline together with a calendar for teachers we chose to create our custom drag and drop library, a few reasons why we must’ve done it:
Besides for the teacher to be able to drag and drop their topics whenever necessary in the Scheme of Work browser, the user also had to be able to change their length, add holiday units or custom content for each one as required. All the business logic that was responsible for managing order of topic units was backed by unit tests, also, all custom sub-components was tested with snapshots to ensure highest quality of our implementation.
Scalable, clutter-free <cyan>education platform<cyan>
Using GraphQL empowered our development process, enabling faster way of requiring custom data. It also reduced amount of performed network requests and decluttered our code.
On the visual part, the DLS improved and speeded up process of creating new views as all the building blocks for those were built beforehand.
The calendar view became approachable and simplified the way teachers could manage their yearly schedule. Creating and editing Scheme of Work is now a pleasant experience where teachers can experiment with different combinations of classes and topic units.
Need help with React or React Native? Let us know!