3 ms·

I am a bit confused by these tools. Can someone analogize what they are doing here? It somehow reminds me of the Django admin capabilities but expanded to any T

I am a bit confused by these tools. Can someone analogize what they are doing here? It somehow reminds me of the Django admin capabilities but expanded to any Typescript base technologies? 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.

smt88 3y ago
> 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. 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.
- zoogeny 3y ago
  If this was a no-code solution I would agree. But the developers themselves are in this thread saying things like: "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." Their github README has a short 75 line snippet that shows the React-ish code one needs to implement a basic dashboard for a generic REST service. One of the top comments was from an operations guy asking: "Why do I have to choose between next.js and Remix?" Clearly they are targeting this towards development teams to lessen their burden and not directly at support teams to roll their own. Choosing between next.js vs. Remix only makes sense to a developer. 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.
detinho 3y ago
I worked at a startup that had many internal tools for solving small problems using Retool. One frontend guy even added a "diff" component so we could compare json payloads and manually edit them. 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.
- debarshri 3y ago
  Retool and others are internal application platforms. The concept exists since the dawn on computer. SAP, IBMs of the world always had one offering like this. 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.
molsongolden 3y ago
Cranking out an admin dashboard in react then also means supporting an admin dashboard. The dev is now on the hook for user issues, additional feature requests, hey can you just add this other field, etc… The dev is interrupted and distracted from other work while the other internal team is slowed down and blocked waiting for the dev to clear their tickets. 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
- zoogeny 3y ago
  My first point, which I elaborated on in another reply to my comment, is that this makes sense for tools that are completely no-code. Refine brags about being developer first. Their example on github is a 75 line React-ish script. So, someone is writing, testing, deploying code. If that isn't your dev team, then who is managing that process and supporting it when someone inevitably borks it? 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.
civan 3y ago
I believe this is an highly productive discussion, and the question narrows down to "which tool is a better match for a specific use-case?" 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.

smt88 3y ago

> 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. 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.

zoogeny 3y ago
If this was a no-code solution I would agree. But the developers themselves are in this thread saying things like: "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." Their github README has a short 75 line snippet that shows the React-ish code one needs to implement a basic dashboard for a generic REST service. One of the top comments was from an operations guy asking: "Why do I have to choose between next.js and Remix?" Clearly they are targeting this towards development teams to lessen their burden and not directly at support teams to roll their own. Choosing between next.js vs. Remix only makes sense to a developer. 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.

detinho 3y ago

I worked at a startup that had many internal tools for solving small problems using Retool. One frontend guy even added a "diff" component so we could compare json payloads and manually edit them. 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.

debarshri 3y ago
Retool and others are internal application platforms. The concept exists since the dawn on computer. SAP, IBMs of the world always had one offering like this. 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.

molsongolden 3y ago

Cranking out an admin dashboard in react then also means supporting an admin dashboard. The dev is now on the hook for user issues, additional feature requests, hey can you just add this other field, etc… The dev is interrupted and distracted from other work while the other internal team is slowed down and blocked waiting for the dev to clear their tickets. 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

zoogeny 3y ago
My first point, which I elaborated on in another reply to my comment, is that this makes sense for tools that are completely no-code. Refine brags about being developer first. Their example on github is a 75 line React-ish script. So, someone is writing, testing, deploying code. If that isn't your dev team, then who is managing that process and supporting it when someone inevitably borks it? 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.

civan 3y ago

I believe this is an highly productive discussion, and the question narrows down to "which tool is a better match for a specific use-case?" 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.