The Technical Brilliance Initiative (BriTech) has quickly become a passion for our team: from an engineering feat, after the first Techathon, to pitching ideas for what we can do next.
As for the second Techathon, Synim Selimi, our Research and Development Lead, held a presentation on “How to build frameworks”, with a focus on truly understanding what frameworks are, why and when we need them, and how to build one.
For us, frameworks are the developer’s best friend. They allow us to be more efficient and creative, while also creating a foundation for future developers to build on. So naturally, we have built our own frameworks, and they are integral to the success of our company.
To fully grasp the idea of a framework, Synim walked us through a few key points.
To begin, one has to ask themself “do I need a framework?”. And to find the answer to this question, well, you have to ask more questions! Web frameworks support the development of web applications, so to understand if you need one or not, you have to have the answers to the following questions:
What are my current needs?
Are they covered by an already-packaged solution?
What skills do I need if I choose a framework?
Will the developed solution be upgradeable?
If all the answers lead you to a single solution (which is that you do need a framework), then the next step is to know which one!
Needless to say that you need a framework that lines up perfectly with your immediate and future needs. To visualize it, you need a framework that:
Solves a targeted problem (or more);
Is a pledge of quality, standards, upgradability, and maintainability of apps;
Has interoperability with market standards;
Abides by its clearly defined conventions.
However, we can’t be selfish here! Even though you are thinking about your framework, it still has to meet certain criteria:
Build for the community - Because no great thing was ever done alone.
Philosophy & convention - Frameworks are not only a development environment but also a new way to think about problems.
Sustainability - A suitable framework is built to last.
Support - Enables the community to guide, correct and adapt to new needs in the future.
Technique and design patterns - The philosophy of the framework should guide specific best practices.
Security - Always build with architectural security in mind first.
Documentation & Licensing - What is a framework if nobody knows what they need it for and how can they repurpose it?
Availability of resources - Are the technical usability requirements of the framework within reach?
After the presentation, the team was presented with a technical problem, which no existing framework has a solution for. In this brain power session, everyone gave ideas on the best ways to solve a specific frontend-centric DevOps requirement. We went through all the evaluation steps on whether we needed a framework or not, and spoiler alert, we needed to build a framework! Synim did a little “show and tell”. He led us through creating a simple framework – jSonic, that builds production-ready frontend code tailored to specific DevOps requirements using a standardized and opinionated approach.
In the end, our team was given the assignment to extend jSonic with the following features:
Auto refreshing;
Clipboard-enabled development;
Hotloading;
Compatibility with another DevOps platform;
Continuous rebuilds.
We are very excited to see what each one of our team members will deliver as a solution for their framework, and who knows, we might be adding something new to our proprietary tech.
Share with your network
The space to share experiences, engage and learn from the Sogody team. Join the conversation by contacting us.