61–70 of 102 posts
Cool product, nice features, too important to rely on such a young company. Sorry to be that guy, but I would never rely the business core on a company like that. That's why I like Tooljet: https://www.tooljet.com (no affiliation) - they are open source. That mitigates the risk to a level that I'd personally accept.
Super interesting. Is the idea that this is like Retool, but a little more dummy'd down (in a good way) and has cron/workflow capabilities?
We get compared to stuff like Retool, Zapier, BI tools and other low-code tools quite often, but the main differences are in the breadth of the product and most importantly how focused on developers and code (Python and JS for now, other language in the future) the product is to make things extensible. Basically we wanted to replace all the internal tooling we've built and used at previous companies we've worked at. A lot of it is too complex for the popular low code tools of today.
We are a ways away from achieving that mission, but think there is an approach that can work if focused entirely on developers.
For us, as developers, it was critical that this type of tool had to be open source - like the other tools we used and came to love and rely on.
Credit for building the platform. Observability is a great idea and something I've not seen before in low code platforms.
For reference, to the wider community, if you are interested in an open source alternative, here's a link to the Budibase github:
Budibase Github Repo: https://github.com/Budibase/budibase
Appsmith is another open source alternative.
Looks good but I don't think I would try any tool unless it is open source as a developer.
Our approach is somewhat akin to say Datadog where they have an agent that you run, but the UI is hosted.
The approach we took was to give customers a) ability to keep data in their VPC, b) security teams can audit anything running in their network, c) anything non-sensitive doesn't need to be hosted by the customer to make it simpler to run/manage.
Would be curious what you think of this hybrid approach and if there are further design decisions we could make that could be useful for us to incorporate?
What’s the lock-in? As in - when we’ve built a UI/app is it locked into a subscription? What happens if you go out of business or we stop subscribing?
Great question, having been an engineer all my life, this is one of the question I would ask myself as well. Developers are at the forefront of our target audience and we want to give all developers the peace of mind that any code or configuration you create in Superblocks is completed owned by you and can keep working without Superblocks. Here's how:
1. Our agent is open-source, this means you can inspect, modify, build and host it however you like
2. We're soon launching a feature where you can export the entire definition of Superblocks apps/workflow/jobs/permissions as project files and manage it in your own git repo
3. We're brainstorming the idea of exporting your app as native React and NodeJS applications so your app continues to work outside of Superblocks
Obviously our goal is to keep providing the best features, performance and stability so you can save time and let us accelerate your development process :)
Would this give you the confidence to use a platform like this? If not, what can we do better?
Looks awesome but how do you handle version control? Also, can permissions be set on who is able to modify vs. view/run a job?
https://docs.superblocks.com/software-development-lifecycle/...
We got some feedback recently that customers wanted to manage this all using their own CI/CD pipeline so we're working toward enabling this very soon. A GitOps feature would allow you to manage everything via your typical process in Github/Gitlab etc including code reviews and team hierarchies on who can deploy code.
In terms of role based access control, we have a set of permissions you can set at the job, workflow and app level for access to Own, Edit, or Use. Also Permissions groups can be accessed via code to do business logic around the groups for more fine-grained controls. There are also permissions at the integration level because you may want developer A to access postgres, but not developer B from another team.
https://docs.superblocks.com/account-management/permissions-...
Still both pretty deep areas we are learning more as our customer base scales so open to feedback!
> while keeping Superblocks up-to-date from our cloud
Does that mean that the OPA auto updates? Or is it saying that I can configure the frontend to use a custom backend?