Pick Your Packer: Building Intelligent Search with Modus and Dgraph
Pick Your Packer (PYP) is “Zillow for Food and Beverage.” They’ve built an easy-to-use platform for conne ...
Learn more
As developers and even as product owners, we’ve been burned before when taking shortcuts. A few years back I was working on a large transformation project, we focused heavily on low and no-code approaches to developing RESTful APIs. The chosen approach involved a low-code RESTful API code generation tool that quickly built out proofs-of-concept. It was groundbreaking for us and allowed for the extremely rapid development of services. We had discovered a new way to develop quickly and effectively and it caught on rapidly.
We were so new to the technology, so in love, that we splashed it everywhere that the organization would allow. The months and years later, though, were not as blissful. They were a complete mess. Our monstrous generated codebase had led us to a crossroads where we were no longer able to build efficiently and within the tangled mess of generated code, a choice had to be made. What happened? We went back to our old way of doing things, building from scratch.
Millions of dollars and thousands of development hours were wasted because we hit the wall with the tech. Our technology golden child was delivered with the promise to do things better but came with limitations we did not see. Was the lesson learned here that these types of platforms were not able to deliver what we needed for the long term? No, I don’t believe so. I believe the lesson learned is that picking the right platform means looking at what the platform can do, where the platform is headed. It also means being realistic with the limitations and customization capabilities of the platform.
After using Dgraph for the first time, I needed to go through this assessment as well. Could a platform that promises such simplicity and power actually deliver what I needed beyond simple use cases? The answer was yes! Yes++. The Dgraph platform contained more stuff than I would theoretically need for any of my use cases.
It’s important to be skeptical though when it comes to technology platforms that will lead to some form of “lock-in”. Most low and no-code platforms do not make it easy to migrate to another platform. It’s an unfortunate reality that all developers, architects, and technical leadership teams have come to terms with. With this in mind, we can aim to turn that seemingly unfortunate nuance into something that is calculated and advantageous.
The idea of being tied to a specific technology platform means that your team knowledge can become specialized and actually lead to even quicker advancements due to familiarity with the platform. It means that lessons learned when using the platform can be applied again and again as more services and applications are built on it. Overall, the advantages of being familiar with a technology are usually plentiful and beneficial. So “lock-in” is not so much the concern as much as being “locked-in” to the wrong or incompatible platform.
What questions should we ask then when looking at adopting a platform which allows for rapid development with minimal code? Here are a few I would suggest, based on experience.
When technology choices were less abundant, we often used certain technologies to solve problems they were never built for. It worked but it meant workarounds, essential knowledge transfer for those unfamiliar with our cryptic workarounds, and sometimes having to turn down feature requests because the platform could simply not handle it without a re-platforming.
With so many technologies available for almost every use case imaginable, it’s important to make sure that the technologies you choose are tested and verified to work for the primary objectives you have. As technology optimists, we often say that we can make anything “work” and likely, we can. In reality, we should try for the easiest path even if it bruises our “we can do anything, with anything” egos. Always embrace the KISS principle.
We often build a proof-of-concept for what we need to do today, not 5 years from now (or even 5 months if we are moving fast). This truly is a “test of fate” when it comes to bringing in new technology since it could lead to the platform not supporting future needs and a subsequent re-platforming of what you’ve already built. It may also mean using 2 platforms to support your newest needs which may turn into a support nightmare for those along the journey.
We can mitigate this by looking at our roadmap (or building one if it isn’t in place) and testing our needs against what the platform supports or aims to support in the future. It’s not an exact science but it can help. For instance, if you know that you will need to support a technology that the proposed platform does not support currently and doesn’t have on their roadmap then maybe there are better options. Maybe another product does already support it plus everything you currently require. This would be a much better fit. This part comes down to a vision of where you are going and good research, along with options, to make sure you can get there.
My final thought on this is to focus on what a platform offers today, not what they could offer tomorrow or promise to implement. The company in charge of the platform could change their mind and delay or cancel a feature, setting you back to square one.
I would say that this is by far the most important question to ask. Perhaps, it could even solve the two questions above if there is enough flexibility within the platform. Most of the time we come to a plateau with a platform when we can no longer customize it to fit our needs. Some of the most highly adopted and long-living solutions allow for high levels of customization while still offering a great amount of functionality out-of-the-box.
Customization is the key to successfully adopting and using a platform for the long term. Look for a platform that allows for customization through the ability to add custom logic or that is open-source and allows for users to tweak the platform to their exact needs. It’s also important to make sure that you look at the ease of customization since you also don’t want to strap your new app into a platform that requires extensive work and knowledge just to implement simple customizations.
In terms of question #1, the primary use case for Dgraph is quite broad. We see users that leverage us for extremely complex knowledge graph implementations but also see very simple use cases as well.
Dgraph can be used as the backend in almost any scenario. We like to consider ourselves a truly unique offering that can be thought of as a multi-purpose database and backend platform. Our platform does offer a great way to get up and running quickly but also has the flexibility to be used across multiple projects within an organization, even with different use cases.
A graph database brings the flexibility of the NoSQL databases that developers love and mixes in the relational support that they are missing from SQL and relational database offerings. This technology underpins the Dgraph platform and is why we can accommodate such a wide array of uses.
For question #2, to build on the answer above, Dgraph is a platform that allows for quick wins during the initial adoption. Unlike other platforms, it also has the flexibility to be a platform that can assist with future needs.
Our support for GraphQL also means that the newest tech is available with ease. GraphQL is giving developers unmatched flexibility and speed. It is quickly becoming a top technology for APIs and we are leading the charge on easy adoption coupled with the latest features the technology has to offer. We also support Dgraph Query Language, or DQL, which is just an augmentation of the GraphQL language which gives developers even more functionality when they need it.
If you’re interested to learn more about GraphQL and DQL, checkout our article GraphQL vs DQL.
Dgraph uses the latest proven technologies to give developers and their organizations what they need today and tomorrow. Just look at some of the companies who are using us for a variety of use cases.
To answer the important topic in question #3, Dgraph supports deep customization in a few ways and with ease. Since we are open-source, developers can extend the platform as they require when using our open-source and enterprise offerings. This gives the ultimate flexibility and community members are also constantly adding great additions to help support the base of the Dgraph platform.
The most common and easiest way to customize the platform though is through Dgraph Lambda. By using JavaScript, developers can create custom code that extends the functionality of the platform. The use of JavaScript also means that most developers will be familiar with the syntax and can quickly implement custom logic. We have plenty of examples that show just how simple it is to get moving with this approach.
Once the logic is implemented, on Dgraph Cloud it is live in a matter of moments. It’s production-ready customization in a matter of a few clicks. This is the most common way for our users to build their logic without limitations. The possibilities of customization are pretty much infinite when using Dgraph Lambda.
Overall, it’s important to be cautious when evaluating new technology. By keeping the 3 questions above at the forefront of the decision-making process, you’ll be much more likely to garner success when making your choice. The effort and cost it takes to bring in new tech is something that you get better at with experience but common mistakes can easily be mitigated with research and knowing your options.
A final piece of advice would be to listen to those who have been through the process before. If you don’t have a technology adoption story that ends with failure, a great place to start is by listening to those who do. Use the lessons learned by others to pave the path of success for yourself.
Whether you’re building an app from scratch or leading a massive digital transformation product, we wish you the best!
