elega Elega Corporation

Announcing NodeBake: An Upcoming New Application Development Platform




Very recently on social media, I invited everyone interested to get notified by signing up at our mailing list over at NodeBake.com to learn more about the upcoming platform's features once it launches. In this blog post, I thought I would lay out a few cool behind-the-scenes details about 1) why we decided to build NodeBake in the first place and 2) the broader marketplace we're entering into and arguably competing in.

How NodeBake Is Built, and Why It's Valuable


NodeBake approaches the problem of needing backend business infrastructure in a way that doesn't adhere to the popularized trends of our time. Its architecture focuses on dedicated compute resources, natively compiled machine code for blazingly fast performance of CPU-bound operations, and leveraging the open-source power of PostgreSQL.

NodeBake will combine the best of both worlds for low code and pro code architecture, allowing you to configure a database server at rapid speed through point-and-click configurations. However, I wouldn't say that NodeBake is meant to be a democratized platform for newbies. We certainly plan to provide thorough and public documentation and want everything to be very easy to learn and use... but the premise of our philosophy centers around a technology that is able to be extremely powerful in the hands of experienced software developers and engineers.


The application layer of NodeBake is written in Rust, a powerful and performant memory safety focused systems programming language. For a few years now, Rust has been the singular programming language internally for Elega Corporation and the same language we're using to create a newly completed edition of our videogame, Kalling Kingdom, as well as our proprietary 2D game engine.

Roadmapped ahead of our upcoming launch (release date pending, stay tuned), we plan to allow developers to create *compiled* automation triggers for their database tables that compile as small, lightweight executables or binaries. What this means is that using multiple compute cores on any dedicated server, your write performance on database transactions will be blazingly fast, buttery smooth, and operate with minimal friction. To begin with, these triggers will be able to be authored in the Rust programming language. Longer term, our architecture allows for support of virtually any programming language that can compile to a spec and consume foreign function interfaces (FFIs).

Okay, but that's roadmapped, what about what NodeBake is launching with? At launch, our database configuration UI and special user & permissions system will be ready to go and available for use. We will allow an advanced mode via the capability to connect to the node's internal PostgreSQL database using any Postgres-compatible IDE. We prefer JetBrains DataGrip but many also opt for pgAdmin.


Responding to Growing Frustrations with Salesforce



NodeBake was inspired by existing products out in the marketplace that I have felt attempt to cover a certain base of features but fail to live up to their promises in execution. In particular, Salesforce, which I've spent over a decade of my career working with as a developer and solutions architect.

For instance, Salesforce seems like a great idea on the surface but then when I learned some of their practices under-the-hood and saw their reveal of JavaScript on the platform, I was baffled. Aura (another JavaScript framework utilized by Salesforce) components were introduced and the community immediately recoiled from the terrible frontend performance that loaded, in many instances, 3x to 5x+ slower than what is now known as the classic UI. Surely, I thought, another competitor will come along to disrupt their platform. Years passed, and nothing very meaningful happened. It seems like all of the natural competitors to Salesforce, ranging from Microsoft to Oracle and other mega-giants: all had other plans and focuses.

You may not know if you're just arriving here: my day job is as a Salesforce Architect. Most sales reps I have ever spoken with despise the platform for a number of reasons, and if you want to dig up any negatives or hate for the platform across the internet, it's not difficult to find complaints. While they've made strides to their frontend performance problems on a percentage basis by introducing Lightning Web Components (LWCs), engineers have continued to wonder why they didn't correct at another order of magnitude. The core platform itself has annoyances or features that are core to how the product works and many of those go unaddressed either in perpetuity or in some cases over a decade before getting any improvement or even just getting resolution to be functional.

So, then, Salesforce began rolling out Agentforce more recently. Don't worry about the UI, you may never need to login to Salesforce again, I paraphrase Parker Harris, the head technology leader at Salesforce for all these years said recently of AI agents. But the truth is, AI has been around for a very long time, and it's only more recently that when people say the phrase AI they are implicitly referring to large language models (LLMs). Chatbots were always going to end up being a part of an experience when a company is building a customer relationship management (CRM) system... but they were never going to become the entire picture.

We all know this. Salesforce knows it. Parker Harris knew it too, even as he uttered the referencible quote. Don't let their enthusiastic marketing pitches fool you. I can comfortably bet a reasonable sum of money that, alongside this not being the first rename and rebranding they've ever done, Agentforce will absolutely NOT be the very last either, with plenty of new market bubbles and trends for Marc Benioff and their executive leadership to chase after.

Don't get me wrong - I respect Salesforce and their leadership. The company is also filled with many extremely talented developers and engineers, and has been for a very long time. The problem is that they've simply made some serious strategic errors and in many important instances haven't been listening to their customers.

All one needs to do to demonstrate this is to go on to the ancient and consistently aging IdeaExchange, where community members have submitted their feedback going back deep into history, and even while some ideas have received massive upvotes, Salesforce has been or continues to be molasses slow in responding to the people who are working every week day to make software on their platform.

Comparing NodeBake to Salesforce (and Others)


NodeBake, even out of the gate, will offer performance that is unparalleled by market leaders like Salesforce. Salesforce requires you use their own proprietary programming language derived from old Java called Apex. Apex compiles to Java bytecode eventually but not before moving through a stifled language interpreter layer and deployment process bottlenecked by dependency checks and turtle-paced tests dragged down by the shared resources mandated by multi-tenancy. In other words, you get a slow programming language that only Salesforce controls or can augment, and the server you deploy to isn't fully yours and there's nothing you can do to optimize its speed.

With NodeBake, you get the raw power of PostgreSQL that is built from the ground up in C, and an application layer built in Rust. These languages are designed for performance and we give you one or more dedicated servers to run your platform. We reject multi-tenancy for dedicated compute - you pay for it, so those compute resources are yours. We won't waste your time unless we have to. In our own testing, we've seen Rust code outpace Apex by more than 1000x in many instances for basic operations, including arithmetic and string concatenations.

The Salesforce database may be built on top of Oracle but you'll never touch the feature set of Oracle or what that database is truly capable of, they lock it away behind their own architecture. That means you can't do basic joins. You can't use simple table aliasing. Aggregate result queries are required over using standard SQL functions. Everywhere you think the Salesforce database looks similar to Java or SQL: it deceives you and steers you just to the side.

NodeBake uses real SQL and real Postgres. No tricks. No abstraction layers. No propretiary language lock-ins. If you read a book on SQL, you can use your skills immediately without learning any of the nuances required by other platforms like Salesforce.

Of course, we can't give you everything because we're not a multi-billion dollar company. You won't get a standard CRM, ERP, or any other data model out of the box, even though we give you all the tools required to rapidly construct your own. So, okay, we're leaving some tables and fields out. But, we plan to give you the ability to deploy your own metadata that spawns the creation of just about any schema you'd like, so that will mean you'll be able to solve that problem either yourself or from open source and third party sellers. Also, stay tuned, chances are we're going to make some stuff of our own as an option.

I would be remiss if I didn't mention maybe the best part of all: pricing. NodeBake will have costs by the instance, not by the seat, which means you can forget about having to pay through the nose just to have a couple hundred users. Nope, the equivalent that will be available will be paying for whatever size server you'd like that meets your needs, and then you can use those resources however you'd like, including deciding the number of users you'd like. We're simply not setting a hard limit. If you can pay for a small server that has a higher number of users, great! We're not going to stop you, and we're not charging per-user. Simply pay us to maintain the server instance and the base licensing cost. That's it, there's no catch to any customer.

We're hoping that this will be a better model that works for everyone out there, and one that makes the power of this kind of software available to more small and medium sized businesses. Of course, we're more than happy to serve the needs of large enterprises too, and we hope that we'll end up growing alongside many organizations out there!

To summarize on features, though, it's important to note that, especially when comparing to Salesforce, there's a number of batteries we haven't yet included, and that's meaningful for a lot of folks, especially those on the low code side of things. We'll be working to close those gaps, again, but here's some important points to consider.





This post has been long enough, I actually don't have time to talk about all the ways in which we're trying to be better than the competition out there. But hey, there's always next time, I appreciate you reading this far! Head over to NodeBake.com and sign up for our mailing list so you don't miss any updates and don't miss out on opportunities around our upcoming launch.