Show HN: A better visual builder for complex business logic(superblocks.com)
superblocks.com
Show HN: A better visual builder for complex business logic
https://www.superblocks.com/blog/introducing-control-blocks-build-any-backend-business-logic-visually
47 comments
As you had a successful Show HN a few months ago, it's probably too soon for another - see https://news.ycombinator.com/showhn.html.
Show HN: Superblocks AI – AI coding assistant for internal apps - https://news.ycombinator.com/item?id=36495680 - June 2023 (62 comments)
Show HN: Superblocks AI – AI coding assistant for internal apps - https://news.ycombinator.com/item?id=36495680 - June 2023 (62 comments)
Our of curiosity, which specific point does it violate? Would it help to remove the "Show HN: " prefix?
Probably easier to think 'what's a thing to post that would be interesting to HN users' rather than 'what are the precise conditions for maximum posting frequency'. 'We're iterating very fast and have some new features' is usually not interesting enough to get around the 'about once a year for reposts in Show HN' standard.
Of course, you can, as you point out, post outside Show HN but the same applies - the promotional effect has to be a consequence of interestingness so if you focus on interestingness, you get both and everyone wins.
Of course, you can, as you point out, post outside Show HN but the same applies - the promotional effect has to be a consequence of interestingness so if you focus on interestingness, you get both and everyone wins.
As an aside, where can one find all of the various rulesets? URL modification to tellhn.html or launchhn.html just resulted in 404's.
I wonder if there's a lack of discoverability of HN rules for lots of folks or if I'm just too dense to personally figure it out.
As I've never posted one of these topics myself, is there some process hijacking in place that will divert folks to the specific applicable rules when they preface their subject with specific keywords?
I wonder if there's a lack of discoverability of HN rules for lots of folks or if I'm just too dense to personally figure it out.
As I've never posted one of these topics myself, is there some process hijacking in place that will divert folks to the specific applicable rules when they preface their subject with specific keywords?
My parent comment linked to the relevant one (https://news.ycombinator.com/showhn.html). It's also linked at the top of https://news.ycombinator.com/show.
The most important other links are https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newsfaq.html, both of which are linked in the footer of every HN page.
The most important other links are https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newsfaq.html, both of which are linked in the footer of every HN page.
Yeah, sorry I wasn't super clear. I'm not a part of OP's company, nor any Y Combinator startup. I'm just an unimportant HN member and saw a target of opportunity to ask you about where some of these rules are defined.
Specifically I was wondering where the rules are for things like Tell HN, Ask HN, or Launch HN (which I think is reserved for Y Combinator companies right?).
However in reviewing the guidelines again which you've kindly pulled out of the footer for me, I'm now noticing I should explicitly not be asking you questions here and should instead be asking through the email address. My apologies.
Specifically I was wondering where the rules are for things like Tell HN, Ask HN, or Launch HN (which I think is reserved for Y Combinator companies right?).
However in reviewing the guidelines again which you've kindly pulled out of the footer for me, I'm now noticing I should explicitly not be asking you questions here and should instead be asking through the email address. My apologies.
Nah, you're an important HN member. No problem.
Re Launch HNs - yes, that's for YC startups - here's a link to the instructions I send founders, in case it's of interest: https://news.ycombinator.com/yli.html.
And while I'm at it, here's what we send them about HN job ads: https://news.ycombinator.com/jobguide.html.
Re Launch HNs - yes, that's for YC startups - here's a link to the instructions I send founders, in case it's of interest: https://news.ycombinator.com/yli.html.
And while I'm at it, here's what we send them about HN job ads: https://news.ycombinator.com/jobguide.html.
That's cool, it's kind of like Scratch [*] for business. Presumably the market is people who don't like Retool because it is too high-level (not enough control) and don't like code because it's too low-level (too much boilerplate and tool complexity).
The risk is that the finer grained control stuff is too much like code ('you lost me at "loop" and "condition"', etc.), or not powerful enough to do the tasks that Retool isn't good at, without diving deep into the weeds, and you're not as good as Retool wrt the tasks that Retool excels at.
Definitely cool that you can extend it with code, though I haven't parsed how that works.
[*] https://scratch.mit.edu
The risk is that the finer grained control stuff is too much like code ('you lost me at "loop" and "condition"', etc.), or not powerful enough to do the tasks that Retool isn't good at, without diving deep into the weeds, and you're not as good as Retool wrt the tasks that Retool excels at.
Definitely cool that you can extend it with code, though I haven't parsed how that works.
[*] https://scratch.mit.edu
I'd love to hear your feedback after taking a few minutes to try it out! We think this will be easy enough for non-developers to grok while also flexible enough for engineers to do whatever they want.
I think "Scratch for business" is an excellent way to think about Superblocks. Like IFTTT or Zapier but with an orientation toward what the old promises of JBPM and similar used to make but could never deliver on. If you can empower non- & semi-technical business users to create workflow apps that will either create eliminate enormous headaches for IT.
I agree. Today we help IT teams solve this with our integration level RBAC but there's a lot of interesting ideas brewing internally for this very problem.
Seconding the comment above, I think "Loop" might actually be a technical term and something like "for each (whatever)" or "do X times" might be easier to follow. As programmers we know things like while loops and end conditions, but regular folks might want to see something a bit more human readable. Alternatively, maybe some kind of flow chart with a line pointing at itself might convey what a loop is - that end conditions are lines that leave the loop's outer box and otherwise the loop continues through the line that points to itself. I sort of feel like "loop" and "booleans" are technical terms that people don't understand as easily as simpler terms like "for each". I'm not sure how you could make something like "x < 5" simpler though. That's basically math and you might have to point folks to YouTube videos about inequalities.
Maybe you'd have more than one person setting this up - the engineer could write some of the details with the help of technical docs for the non-techie, but then someone experienced could provide someone less experienced with comments to follow or higher-level descriptions of blocks? E.g. At a high level there could be a human description that says "Load data: While there's more data to fetch ..." or "For each record, relabel fields..." but at a low level, it might say "While len(response) > 0, fetch data" or "Assign object fields x,y,z to response fields a,b,c".
Maybe you'd have more than one person setting this up - the engineer could write some of the details with the help of technical docs for the non-techie, but then someone experienced could provide someone less experienced with comments to follow or higher-level descriptions of blocks? E.g. At a high level there could be a human description that says "Load data: While there's more data to fetch ..." or "For each record, relabel fields..." but at a low level, it might say "While len(response) > 0, fetch data" or "Assign object fields x,y,z to response fields a,b,c".
This is great insight. Taking a more "technical" approach has its tradeoffs but so far, our customer discovery points to this being a tangible approach to try for enterprise use cases. We find that a lot of enterprises assign engineers to build in Superblocks but rather than a team of 100 engineers building out a DIY solution, they can reduce it to only a handful.
I am excited to experiment with in-product guidance and a/b test copy so that we can make things just as intuitive for those who may not be as technical.
I am excited to experiment with in-product guidance and a/b test copy so that we can make things just as intuitive for those who may not be as technical.
Maybe take a look at cobol.
I know, I know. But it was designed for non programmers.
Their syntax in this case is
Perform . . . Times
The language might give some insight by offering a different perspective
I know, I know. But it was designed for non programmers.
Their syntax in this case is
Perform . . . Times
The language might give some insight by offering a different perspective
TIL! That syntax reminds me of Ruby a little bit.
Looks cool, but you lost me at the SSO Tax on your pricing page.
All you are missing now is a 'scratch pad' to 'sketch out' an idea without any definites. Like take a nomnom/mermaidjs flow chart and let me 'flesh out' each block with the control blocks.
Each one of these "APIs" has a json/yaml DSL that could be constructed with any builder pattern. We just haven't released a public API for this yet.
> With Control Blocks, developers get a visual programming language that looks, feels, and scales like code.
What problem does that solve? I get that there are situations when a programming medium that doesn’t look, feel, and scale like code might be useful, but when the right solution is something that looks, feels, and scales like code, isn't that what is solved by code?
What problem does that solve? I get that there are situations when a programming medium that doesn’t look, feel, and scale like code might be useful, but when the right solution is something that looks, feels, and scales like code, isn't that what is solved by code?
Perhaps. Those who want to do that can leverage our Javascript and Python blocks to write whatever code they'd like.
Most of our platform is centered around "integrations". For example, You'd have a visual block for an S3 integration (that would have been previously configured) that you'd use rather than initializing an S3 client in code for example.
We want to meet people where they're at though. If you want to write code, you can do that but if you want to use a more visual approach, you can do that as well.
Most of our platform is centered around "integrations". For example, You'd have a visual block for an S3 integration (that would have been previously configured) that you'd use rather than initializing an S3 client in code for example.
We want to meet people where they're at though. If you want to write code, you can do that but if you want to use a more visual approach, you can do that as well.
Another way to maybe approach this is to consider programming constructs that are "hard" to understand. Imagine you want to "do n things in parallel". If your company uses Java (or any language where it's no trivial to do concurrency), this is not straight forward. A visual way to do this makes it much easier.
Does this handle tasks in different timezones? Is there a map interface? Like, say I've got to manage multiple drivers over multiple timezones, and I need to know who's got an hour left on their shift, what they're hauling in their truck, and where they are on a map.
Superblocks can absolutely be used to build something to solve this use case.
I love the idea of low code/no code for fast prototyping and experimentation. We use Zapier extensively for exactly that. Once the experiment is tweaked and considered a success, we port it to code.
The problem comes in the middle phase, after until deployment and before turning it in to code: version control, debugging, collaboration etc is all a nightmare with no/code and so if any experiment gets too big it’s a real pain to deal with.
The problem comes in the middle phase, after until deployment and before turning it in to code: version control, debugging, collaboration etc is all a nightmare with no/code and so if any experiment gets too big it’s a real pain to deal with.
I agree. We believe we've pulled off what hasn't been done before and solve the issues you mention. We're adding "step though debugging" (simple version is live today), version control (upcoming weeks), etc. to give an enterprise ready experience.
Discussed recently here https://news.ycombinator.com/item?id=36495680
This is actually a completely separate feature! We're just iterating fast! Our AI launch introduced the ability to have AI generate and refactor code for you in our platform.
Right but that's not really the cadence of Show HN which has its own weird rules.
I usually expect "Show HN" posts to be about new products/projects you’ve worked on, not to post every feature annoucement of your company.
Also:
> Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. You'll get more feedback that way.
https://news.ycombinator.com/showhn.html
Also:
> Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. You'll get more feedback that way.
https://news.ycombinator.com/showhn.html
Thanks for this! I personally wrote a significant portion of this feature am very excited about this new tech!
Unfortunately we require email to signup but have a free trial. Users are able to test end to end in just a few clicks.
Unfortunately we require email to signup but have a free trial. Users are able to test end to end in just a few clicks.
Some questions:
- can I self-host the whole suite without any internet connection?
- Are you targeting retool users?
- Are you targeting airflow users?
- can I self-host the whole suite without any internet connection?
- Are you targeting retool users?
- Are you targeting airflow users?
We provide an agent deployment model that allows your data to never leave your network. We do not however offer an air-gapped solution.
Superblocks, Retool, and Airflow provide different approach to solve similar problems. We've found that lots of customers prefer Superblocks.
Superblocks, Retool, and Airflow provide different approach to solve similar problems. We've found that lots of customers prefer Superblocks.
> We provide an agent deployment model that allows your data to never leave your network
I had i rapid look at the docs and, for what I understand, the agent is "dumb" and need to continuously contact your cloud (similar to github/gitlab ci runners) and also the user interface is on cloud. Correct?
I had i rapid look at the docs and, for what I understand, the agent is "dumb" and need to continuously contact your cloud (similar to github/gitlab ci runners) and also the user interface is on cloud. Correct?
The UI executes APIs against this agent which talks to Superblocks to fetch API definitions to run. These definitions will be "signed" by a key that only the agent is the authority of so customers can guarantee that it hasn't been tampered with.
How does this compare to Retool Workflows? https://retool.com/products/workflows/
or other OSS projects that are similar, like https://n8n.io/
n8n AFAIK is a workflow builder whereas at Superblocks, we are an Application builder (in addition to a workflow builder). We enable developers to build user interfaces that "bind" to APIs that they build with this feature.
I have yet to see a drag-n-drop workflow framework that captures the developer market. Every tool eventually lands on citizen developers.
Writing the code always ends up being easier and you can build visuals on that if you really need them.
Maybe this is closer to https://bubble.io/? (https://manual.bubble.io/help-guides/logic)
Writing the code always ends up being easier and you can build visuals on that if you really need them.
Maybe this is closer to https://bubble.io/? (https://manual.bubble.io/help-guides/logic)
I've used it a bit and find it to align more with the free form node approach where the lines between them define the "control". I think this approach where we introduce a visual programming language has the potential to change the way the industry views products like these.
There's something about the ability to drag on a try catch, use a native break block in a loop, etc. that feels very "like code".
There's something about the ability to drag on a try catch, use a native break block in a loop, etc. that feels very "like code".
Are you a PM at Retool?
Reminds me of SharePoint 2010 workflows, and eventually Apple's Shortcuts.
Does it work on localhost?
Yep! You can use our agent to run it locally with Docker. Just go to "org settings -> agent" in our site and use the deployment instructions.
What about versioning? Can I store the workflows in my git repo?
You'll be able to in a few weeks! Stay tuned.
We just launched “Control Blocks”, a visual builder for backend business logic that enables developers to drag and drop “blocks” (conditional, loop, parallel, try/catch, variables etc.) onto a canvas and construct cohesive business logic that reads linearly like code.
The industry's approach to visual builders thus far has primarily been free-form flow diagrams where lines define the “control”. This approach works fine for a small set of blocks. However, as logical complexity increases, it quickly becomes impossible to read and debug. We wanted to take a much different approach that catered to the enterprise developer by retaining the same abstractions as code.
With Control Blocks, developers get a visual programming language that looks, feels, and scales like code. We provide the core primitives that allow you to build visually in Superblocks what you would through code. Some of these primitives, such as our take on parallelism, offer a much simpler abstraction than code. With this approach, operations like debugging and refactoring feel much more “native”. With this as our foundation, we’ve found that it is much easier to design features for testing, tracing, reusability, breakpoints, generative AI, and more.
On the technical side, we used this as an opportunity to improve our core execution engine so that it can provide the performance and reliability needed for enterprise usage. We migrated from TypeScript to Golang and started utilizing V8 for our binding resolution engine.
Read the linked blog and watch the embedded video and let’s have a conversation about your thoughts on our new take on this visual builder.