Launch HN: Refine (YC S23) – Open-source platform for enterprise web apps
Check out our online generator at (https://refine.dev/#playground) to create a custom Refine application and download it.
Before starting refine, we spent five years as a consultancy company building internal-facing applications for enterprise clients. We have seen many complex use cases where the demanded flexibility was much higher than what existing low-code/no-code solutions provide. Moving away from rigid architectures and pre-made components that are difficult to customize, developers tend to start from the scratch. This results in a significant waste of time and resources.
In order to find a sweet spot between “starting from scratch” and higher level solutions, we started working on refine. After a couple of iterations, we came up with a “headless” solution, separating the UI-layer completely from the rest of the frontend logic. This allowed us to support multiple UI frameworks and custom designs out of the box.
We understand the importance of frontend developers working with the stack and tools they love and are familiar with. So, we have built our project creation wizard that allows developers to mix and match their technology stack when creating a project.
After 1.5 years of development with the great support of the open-source community, Refine has become a mature framework that allows developers to rapidly build enterprise applications and have 100% control over their projects.
While remaining unobtrusive, Refine still saves a lot of development resources by eliminating repetitive tasks such as CRUD operations, state management, routing, authentication, access control, and i18n. It’s also backend-agnostic and works with any APIs or services.
The best way to start Refine development is visiting our extensive documentation at (https://refine.dev/docs/). Here, you can also find tutorials and real-life examples to use as a starting point for your use case.
We had one successful Show HN earlier this year (https://news.ycombinator.com/item?id=34515128), and have since had several major releases and added many more features.
Recently, we've released our enterprise edition featuring deployments, built-in security, backend integrations and auto-generated UI's. By expanding Refine's capabilities beyond the frontend, the enterprise edition offers a complete solution for the internal tooling requirements of larger organizations. To get more information, please see our pricing page: https://refine.dev/pricing/.
If you have any questions, ideas or suggestions please share them with us. The team will be here all day to answer. We look forward to all of your comments!
93 comments
[ 2.7 ms ] story [ 165 ms ] threadHow does your product compare to Retool and other products in the space including the OSS ones (Appsmith, Windmill, Tooljet etc)?
With react-admin, you have no choice other than using Material UI for your app. refine's provides nearly all the features of react-admin enterprise provides as open-source.
Since refine's architecture is headless, router logic is completely detached from the business logic and UI layer. So you can use refine with React Router, NextJS, Remix, or any other framework may pop-up as long as it's React based. With react-admin, you can only use react-router and it doesn't have a real SSR support, while with refine, you can use SSR frameworks like NextJS and Remix without being limited.
Short story: Refine and react-admin were in the same low-code space (targeting developers) until today, but it seems they've pivoted to no-code (targeting non developers) as they go after ReTool.
Long story: https://marmelab.com/blog/2023/07/04/react-admin-vs-refine.h...
One of the key differences is our code-first preference over no-code, which distinguish Refine from the drag-drop style workflows of Retool, Appsmith, Tooljet, Budibase etc.
Instead of offering a fixed set of pre-made components, Refine outputs a real React project with collections of helper hooks and providers. The "headless" architecture enables developers to integrate any preferred UI framework or custom design, thereby maintaining the highest level of customization and styling options.
This level of flexibility fits use-cases like complex admin panels, SAAS interfaces and B2B portals rather then single-page internal tools which require little or no customizations.
edit: link https://github.com/windmill-labs/windmill
I know, I know, they're covering their bases, but nonetheless find it if only slightly amusing.
Piss-off a VC and they might back your competition. Get on their good graces and they'll give you both money and wait to see who comes out on top.
I don't know what that means, and what the implication of choosing between Vite, Remix, or Next.js -- it's meaningless to me.
https://devboard.gitsense.com/vitejs/vite
https://devboard.gitsense.com/remix-run/remix
https://devboard.gitsense.com/vercel/next.js
The only other project that I've seen with greater engagement than next.js on GitHub is Microsoft's vscode.
Full Disclosure: This is my tool.
I did some work as part of my consultancy, had data left and decided to try my hands at frontend. Oh, boy, I think it was a mistake, but it was a lot of fun, will do again. https://cloudprice.io
Our goal and motivation in developing refine is to ensure that the developer continues to feel the way they felt on the first day, even on the day they finish the project and begin to maintain it.
I have trouble wrapping my head around the use case for this. Is the target market existing businesses that already have APIs (probably as REST services), maybe some databases and they just want to quickly wire up some UI to it? It seems a bit heavy handed for writing an entire application.
I can imagine maybe a medium sized business where the data science, sales, marketing, customer service etc. teams want some access to the production system data in a format other than Tableau or Microsoft BI. And perhaps their engineering team is entirely focused on product development or operations and so no significant resources can be allocated. I guess this might allow more junior or jack-of-all-trades engineers to whip up basic admin features?
To be honest, even in small startups I've worked at, cranking out admin dashboards using React was just so trivial that I can't imagine paying to make it slightly easier. And looking at their code examples, it doesn't seem all that more simple. I suppose there maybe some goldilocks zone between startups that just crank that kind of stuff out and huge enterprises where entire teams exist to manage internal tools. In that zone perhaps having these kinds of platforms can expedite internal tooling creation.
I haven't tried Refine, but with Retool, we had non-developers able to build themselves functional admin tools in literally minutes.
Writing new code, regardless of how great the React components are, just doesn't come close. I can do things with Retool in 2-3 hours that used to take a week or more of a senior React dev's time. It's at least one order of magnitude of difference, maybe more.
As for "2-3 hours" in no-code vs. "1 week" for a developer, I might challenge that. In many cases if a support team (sales, customer service, marketing, etc.) asked a product team to build something custom for them then they are going to quote product development timelines. However, Most places where I've worked where admin tooling was expected and high-quality the admin features were part of the product feature development. In general, most functionality would be added in some small part of the feature dev time. For example, a 2 week sprint for a new product feature might include 1 day of adding functionality related to that feature to the admin. That is to say, your 1 week quote is almost definitely not the time it would take to add the features but a block of time the product team is quoting to make you go away. That is an org problem, not a technology problem. With Refine, I don't think you will bypass this problem since you will need someone capable of using at least React and whatever stack you configure the tool with.
I have to admit that it's not the best of the worlds, but for small, focused internal interfaces that call some APIs, it can serve well.
Don't know about this new tool, but talking of retool itself, I also don't see it being used for a full fledged customer facing application.
You always need an internal platform may be for seeing the order status of the shipped product or some customer data etc. The consumer of the tool is a customer service agent or an internal employee etc. These tools does not have to be perfect , they have to be functional.
It has always been a huge market as it saves ton of money for an org. These days as building UI and APIs have become democratized, the market for internal applications platform have become very competitive.
If you have semi-technical users (can muddle through generating SQL using stackoverflow) then unleashing them on a read-only DB copy with an app builder can be better for everyone involved.
Something like: “Hey I saw your ticket requesting a ‘user address’ field in the dashboard, do you want the mailing address or billing address? Lmk then I can probably add this today and it’ll go live in the next deploy” -> user instead adds the field on their own in < 5min
Lots of additional use cases for other db interactions too where “let’s just spin up an internal admin panel in the app” can turn into days or weeks of getting input and now the design needs to be thought about and more stakeholders consulted vs. absolute basic functionality being stood up in Retool in a couple of hours. It’s sort of similar to presenting a wireframe instead of high-fidelity mock-ups
My second point is that even no-code tools tend to require developer support sooner or later. What I've noticed for admin tooling is that it often works best when it is driven by the product team. For example, customer support requests comes in which requires devs to stop working, investigate the issue, manually fix up data where necessary, etc. Devs hate doing this. Give the dev the ability to add the functionality to the admin and they often will, just to make the support requests go away. If you take away the admin from the product team then there is more friction in this path.
I will admit however, that the quality of life improvements demanded by the support teams often go un-attended. But I don't see how Refine will help this go away if it requires someone familiar with next.js/React, Ant/MaterialUI, etc. to make changes.
Refine does appear to require developer build-out and is more of quickstart framework.
The domain of internal-facing applications is quite diverse. One use-case can be a single page internal tool, triggering a small script. On the other extreme, organizations build SAAS/B2B interfaces with 10+ pages/resources maintained by dedicated development teams.
Need to deploy atomic internal tools where technical and non-technical roles collaborate? Retool, Superblocks, Appsmith, Tooljet or Budibase are perfect solutions. Turning scripts/workflows to basic UI's with integrated security and observability? You can choose with Windmill, Airplane or Onu. You don't want any overhead or learning curve for your lean project? Start from scratch and build with the great tools React community offers.
Refine becomes a better option for complex cases and higher customization requirements. You can give it a try if * You have to implement a custom design / design system, * You want to be able to customize your stack instead of locking in a black-box architecture. * You a need robust architecture for your long-lasting project proven by thousands of community members.
Budibase https://github.com/Budibase/budibase
Appsmith https://github.com/appsmithorg
Tooljet https://github.com/ToolJet
We also have this 'headless' feature that lets developers seamlessly blend in their favorite UI framework or their own custom designs without any hassle. This flexibility is particularly great for things like complex admin panels, SAAS interfaces, and B2B portals. On the other hand, if you're working on simpler tools for internal use – you know, the ones that don't need a lot of tweaking – Refine might offer more complexity than necessary.
To us, low-code is really about creating simpler, or higher up the logical stack, abstractions, and then generating the implementation.
Our take is not so far off from yours, where we take a code first approach. Users declaratively define their application in CUE and then get most of the code. Rather than providing hooks, we let the user write directly in the output code. Unlike Refine, we enable our tool to continue to aid the developer beyond the initial scaffold phase, allowing things like the data model to update and the user gets new database migrations to be auto-generated and applied. We also make it really easy for anyone to create and share these application blueprints or generators (as we call them).
In this way, the user can select any mix of technology and make starterkits or addons for any application, not just webapps. For example we have users (ops team) injecting and maintaining CI & k8s files into their service fleets (dev team). This is a case where we see low-code, as a term, more generally.
https://github.com/hofstadter-io/hof
co-founder here :)
We sincerely appreciate your understanding. While we regret any previous oversight in responding to your enterprise inquiries, we're actively addressing all incoming applications now. Your interest matters a lot to us, and we're working to ensure a smoother experience.
Because they market it like that. Their tagline is "Open-source Retool for Enterprise", and retool is a nocode (or low-code) tool.
I assume you have no ties to Retool but using it to explain your product ? Sounded like it is a product offered by Retool so you might want to rethink that.
Edit: never mind, people are still complaining so I backtracked.
I'm a noob. Retool can be used by a noob. Your tool can't, so it's not a Retool. That's just the bitter truth.
Other very similar but less code-heavy solutions include appsmith, tooljet, or budibase.
In the same spirit, but SQL-only instead of based on javascript, I am currently working on https://sql.ophir.dev . It also allows building entire data-centric applications and internal tools very quickly, but without having to think about things like "remix", "vite", or "next.js", which sound like chinese to most non-developers.
It basically seems to use SQL (instead of e.g. JSX) as the component configuring/templating language (in addition to querying). Which is a little odd, but does work for simple use cases like tables, cards, and grids.
I'll give it a try the next time I have to quickly present an SQL query as a non-customised report. Thanks!
Refine looks more like a headless retool for software engineers that are comfortable with frontend frameworks but want an opinionated stack that is tailored toward internal uses and do not want to deal with the rest of the boilerplate, user management, and connection/management of databases etc. I could see myself preferring refine for some use-cases and would probably recommend it if you are comfortable with writing frontend and the logic is limited to CRUD. So I wish them good luck and I am happy to see such diversity in the open-source space!
Nice to see you giving a positive testimonial to another company with some overlap, rather than tilting at windmills
https://win95.refine.dev/
This thing looks nothing like Retool. As other people have mentioned here, Refine "just scaffolds your codebase, gives you a good start, and has some cool hooks". So the whole "Open-Source Retool Alternative" angle seems very confusing and off-base to me. They look like very different tools built for very different audiences, imho.
Seems like you're trying to piggyback on the Retool wave. Why not just be honest (and a bit creative, perhaps) with your marketing? My $0.02
I am researching viability of no-code tools like Retool as a business and was wondering if you were developer preferring Retool over coding to save time and resources for internal tools vs a non-developer trying to take care of the business without bothering the development teams.
Our target audience is the developer who doesn't believe that building a simple form (that submits a POST request) should involve: 1) installing 30 dependencies, 2) learning a new framework, 3) spending hours researching the best table library, and 4) mucking around with redux trying to figure out how to get a spinny indicator on a button.
The state of web development today is _insane_, and we want developers focusing on being productive, instead of everything listed above. (Fortunately for us, most developers agree and think that web development has gotten too complicated, especially for simple internal forms.) Developers who want to ship is our market, not "non-developers" who don't know how to code.
Perhaps we should write a blog post about this one day, hmm...
(David, founder @ Retool here.)
Landing Page / Initial impressions
* You mention "enterprise" a lot on the landing page, along with being open-source, but then you also call your commercial version "enterprise". It is a tad confusing delineating what is what. Having built and sold developer facing tools, *I* have enough context to understand that you mean is "this isn't a toy, you can actually use it in for-real production apps with for-real big company requirements even in open source", but I don't think you are doing yourself favors by calling your commercial tier enterprise, as it really confuses the message.
* The above is made a bit worse by the fact that you don't have any mention of a commercial product on your landing page, so when I got to pricing (usually my second page) and see enterprise, now I am not sure if the landing page is just for commercial project and open-source is just a toy.
* As far as I can tell, you don't have any marketing pages for the enterprise offering beyond the pricing page? I want to know how it differs. I want to click on the list of additional integrations. I want some docs. Anything you can give me besides contacting sales is going to help. I am not saying it is a paper launch / painted door, but it seems like one, and a thin one at that. You may have a really great product, but your GTM seems like it is lacking, and GTM for products built on open-source is super important, but generally underdeveloped by dev led teams.
* Your landing page doesn't really tell me who the target audience is, unless I have context of another product. I totally get a play that uses the momentum of another company, but I do think you lean on it a bit too hard here. I need a tagline like "Refine is an opinionated project builder for React developers designed to 10x your ability to stop fighting frameworks and start getting work done" or something to tell me who this is for without relying entirely on knowing retool. Similar, the enterprise product has really compelling features, but without more context on pricing, use-cases, etc, I don't know if it is for me.
* Your CTA and getting started is reasonable, but, as others mention here, it is giving the user a ton of choices that they may not have a clear idea of pros and cons. I suggest changing from a horizontal card arrangement to a vertical card where you have more space to provide some guidance.
* Animations and graphics for marketing pages is very subjective, but imo, the animation of the different domains of front-end apps (backend, react, auth, etc) along with the rotating list of "enterprise-ready" features is really busy and don't tell me much. I kept thinking that the firing concern would link with the enterprise ready feature, but it seems they were unrelated which just made it noisy.
Architecture / deployment model / commercial differentiation
* Are you doing the hosting directly for enterprise version and including the direct database access? If that is hosted in your cloud... that seems really tricky security wise. If you are hosting in the customer account that seems really tricky in terms of a wide range of clouds etc. I would be curious to know how this has gone so far.
* With enterprise and the direct database offerings, it seems like you have two choices of generating APIs that connect to DBs or are doing a more "direct" API that can execute SQL. Both have challenges. is there anything unique there on offer?
* The differentiation of features between open source and commercial seems reasonable... but I am concerned that because you don't have *any* ability to use any server side integration, it becomes such a different beast that you don't have an opportunity to get people to learn it. I would think that moving a "taste" of the serve...
That’s a very specific percentage of effort to eliminate. How did you arrive at that figure?
You need a license to get the Enterprise code. Many other software work this way.
I'm curious about what their Enterprise license looks like and what you can and can not do with the code.
closes tab