3 ms·

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,

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.
- molsongolden 3y ago
  Ah, I hadn't tried the Refine demo and was going totally off of past Retool experiences where creating or modifying an app can mean just picking a UI component and adding SQL. Refine does appear to require developer build-out and is more of quickstart framework.
  - buremba 3y ago
    You can build low-code tools with Refine though. One of my side projects Jinjat (https://jinjat.com https://jinjat.com) uses Refine as the UI framework to render the data models that you have in your dbt project, as an example. Retool is an end-to-end tool whereas Refine focuses on the front-end and gives the flexibility in the backend for your business logic, which is often hard to scale out with Retool.

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.

molsongolden 3y ago
Ah, I hadn't tried the Refine demo and was going totally off of past Retool experiences where creating or modifying an app can mean just picking a UI component and adding SQL. Refine does appear to require developer build-out and is more of quickstart framework.
- buremba 3y ago
  You can build low-code tools with Refine though. One of my side projects Jinjat (https://jinjat.com https://jinjat.com) uses Refine as the UI framework to render the data models that you have in your dbt project, as an example. Retool is an end-to-end tool whereas Refine focuses on the front-end and gives the flexibility in the backend for your business logic, which is often hard to scale out with Retool.