Don't Reinvent the Wheelâ
As software developers, we are all familiar with the phrase "Don't reinvent the wheel". However, I have heard many complaints that the Javascript world seems to do the exact opposite. đ
As software developers, we are all familiar with the phrase "Don't reinvent the wheel". However, I have heard many complaints that the Javascript world seems to do the exact opposite. đ
As a software developer, you may not have directly participated in any open-source project, but you have likely benefited from the open-source world unless you don't use Git, GitHub, or Linux. đ In return, many of us would like to contribute and be a part of this new wave of collaborative and transparent development.
Having been involved in the development of four commercial SaaS products at my previous company, I've come to realize the multitude of complexities that arise compared to typical consumer products. Among these complexities, one prominent area lies in the intricate realm of permission control and access policies.
Have you ever built a product from scratch? If so, I bet you definitely experienced the trade-off between the design quality and time to market. In fact, you might have to struggle with it more than you expected. In Shopify's practice Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity, they get the conclusion below:
In conclusion, no architecture is often the best architecture in the early days of a system. This isnât to say donât implement good software practices, but donât spend weeks and months attempting to architect a complex system that you donât yet know. Martin Fowlerâs Design Stamina Hypothesis does a great job of illustrating this idea, by explaining that in the early stages of most applications, you can move very quickly with little design. Itâs practical to trade off design quality for time to market. Once the speed at which you can add features and functionality begins to slow down, thatâs when itâs time to invest in good design.
When I quit Microsoft and joined the startup company in 2015, the first thing I learned is the concept of Microservices. It was touted as the future of software development, promising increased scalability, flexibility, and resilience. It seems everyone was jumping on the bandwagon, even the fledgling startups despite the inhere challenges involved. There was a joke about it:
Thereâs a thousand-line program here, weâve got to break it to make it down into 10 hundred-line programs.
Almost all the SaaS now is collaborative, from the originator Salesforce to the newly emerging one like Notion. To make it collaborative, technically, we need to build the foundation to support tenant isolation with an access control policy. A classic challenge here is striking a balance between app security and dev productivity. ZenStackâs access policy provides an innovative way to achieve that balance using the declarative schema.
I still recall the day that my co-founder approached me with his plans and asked if I wanted to join him. Usually, when I'm presented with a similar opportunity, the first question I usually asked is:
What makes this thing different
But this time the question I asked was:
Why do you want to build it
Why? Because of the book âStart with WHYâ. This simple yet powerful question uncovers the true motivation behind a project and is what truly inspires people.
No matter what programming language you are using, one common suggestion you all probably hear is that:
Donât use switch statements
Besides people usually forgetting to add the break statement, the more profound reason is that developers often avoid using special cases in their code. Instead, they prefer to use more flexible and powerful constructs such as polymorphism or dictionaries.
Django is a popular Python-based web framework. Itâs a huge so-called âbattery-includedâ framework covering many aspects of web development: authentication, ORM, forms, admin panels, etc. Itâs also a strongly opinionated framework that offers patterns for almost everything you do, making you feel well-guided during development.
If you are a developer familiar with RESTful APIs, you might have heard of OpenAPI. It is a specification for describing RESTful APIs in a format readable for humans and machines. Building a public-facing OpenAPI includes three tasks:
In this post, you'll see how to accomplish all these tasks and build a database-centric OpenAPI service, secure and documented, within 15 minutes.