Declarative Forms inside requests to interact with api's

[mackwic]

Hi Anoop,

Would you consider a way to declaratively define a form to the users, that would bind to a request payload?

JSON Form is a good example of what I am thinking of. It is not great per se (documentation is poor and the schema is complicated), but it's a simple easy way to make easier interacting with the API when we need a payload.

[helloanoop]

Sure, this seems to be a great idea!

If I understand you correctly, what you are saying is

• We should be able to define a schema (ex: via json form)
• This form gets rendered in a tab in the request pane.
• The user can then enter the details and hit send.

I would love to know a bit more details on how it makes your workflow easier. Could you share a more concrete example, and how a form would look like for your use case?

[mackwic]

I want to be able to use bruno as a proto-backoffice to interact quickly with our api. Before that, we used postman.

Reasons why I'd like to show a form ui rather than a JSON textarea:

• less typo or "\"" madness
• it's less frightening for non-techies roles (think: customer support. some sales-ops or finance-ops person)
• the form has some kind of validations: it's less error prone
• the labels, placeholders and descriptions help with discoverability. This also reduce the pain of procedure writing as more things are in the UI.

Does that speak to you ?

After digging a bit more, I find Formkit Schemas to be better, but sadly it's not compatible with React only Vue.

[helloanoop]

Hmm.. This closely resonates with the Apps functionality in the roadmap.

Here is a rough idea of how I am imagining the Apps functionality to work.

• Apps exist inside collections.
• Each dashboard has js, css, html files.

Here is how folder structure would look like:

collection
  |- bruno-apps
      |- sales
          |- view.html
          |- scripts.js
          |- styles.css
      |- marketing
          |- view.html
          |- scripts.js
          |- styles.css
  |- sales
      | - get-sales.bru
      | - get-sales-by-region.bru
      | - get-sales-by-product.bru
  |- bruno.json
  |-collection.bru

An app is a "miniature view" that you can build using html, css, js. It can be a dashboard, a form, a table, a chart, etc.

Ex: A sales app that displays sales data in a table.

index.html

<div class="flex">
  <div class="flex-1">
    <h1>Sales Dashboard</h1>
    <table id="sales-table">
      <td>Quarter</td>
      <td>Revenue</td>
  </div>
  <div class="flex-1">
    <button id="refresh-button" class="btn btn-primary">Refresh</button>
  </div>
</div>

scripts.js

const refreshButton = document.getElementById('refresh-button');

refreshButton.addEventListener('click', () => {
  bru
    .runRequest('sales/get-sales.bru')
    .then((data) => {
      $('#sales-table tbody').empty();
      _.each(data, (data) => {
        $('#sales-table tbody').append(`<tr><td>${data.quarter}</td><td>${data.revenue}</td></tr>`);
      });
    });
});

Its a nice way to quickly build out mini-apps that interact with your api (that are defined in the collection). This feature is being planned as a part of the Golden Edition

It seems you should be able to achieve your use case and be able to build all kinds of functionalities with this.

[mackwic]

The thing is, we want to use an API wrapper because we don't have the time to build a frontend. Your proposal seems like building a mini frontend... without all the nice tools I would have in a frontend project (eg: components library, validation logic, CSS architecture or design system...).

It's not clear to me how a bruno app would be better than spin up a little nuxt/next project that wrap my API. It would be far more comfortable at least

[helloanoop]

It's not clear to me how a bruno app would be better than spin up a little nuxt/next project that wrap my API. It would be far more comfortable at leastuse

You are right. For, anything a tad bit complex spinning up a little nuxt/next project would makes sense. That said, I believe there are places where the idea of "bruno-apps" could be useful. I will make a short demo once I have something tangible.

The thing is, we want to use an API wrapper because we don't have the time to build a frontend.

I think we should still be able to use react-jsonschema-form, This library was a key part of our stack at my previous company. I can vet for it strongly.

I like the forms idea, and am open to building this functionality in Bruno.

In terms of designing this out, here is how I am thinking

• At the request level, a user can toggle a switch inside the settings tab to enable Forms
• Once enabled, a Form tab will appear as the first tab inside the request panel which cab edited like how we do it today for Docs tab

Then you can get the form details and populate the payload inside the pre-request script

let formData = bru.form.getData();

bru.setBody({
   name: formData.name,
   email: formData.email
})

Also, I am still contemplating whether this should be a part of our Golden Edition offering. Although majority of Bruno is opensource, we do have paid addons that are planned and I am working on it fulltime.

[mackwic]

Great idea ! It totally should be part of the golden edition, it's for pro users.

Would we be able to store the schema ui with the bru files ? (maybe inside them?). I believe the API provider has the bes knowledge to propose the associated form.

[helloanoop]

Would we be able to store the schema ui with the bru files ? (maybe inside them?). I believe the API provider has the bes knowledge to propose the associated form.

@mackwic Yes, it would be stored inside the bru file itself.

get {
  url: https://www.example.com
}

form {
  {
    "title": "A registration form",
    "description": "A simple form example.",
    "type": "object",
    "required": [
      "firstName",
      "lastName"
    ],
    "properties": {
      "firstName": {
        "type": "string",
        "title": "First name",
        "default": "Chuck"
      },
      "lastName": {
        "type": "string",
        "title": "Last name"
      }
    }
  }
}

[mackwic]

that's great 👌

Le lun. 8 janv. 2024 à 10:06, Anoop M D @.***> a écrit :

Would we be able to store the schema ui with the bru files ? (maybe inside them?). I believe the API provider has the bes knowledge to propose the associated form.

@mackwic https://github.com/mackwic Yes, it would be store inside the bru file itself.

get { url: https://www.example.com }

form { { "title": "A registration form", "description": "A simple form example.", "type": "object", "required": [ "firstName", "lastName" ], "properties": { "firstName": { "type": "string", "title": "First name", "default": "Chuck" }, "lastName": { "type": "string", "title": "Last name" } } } }

— Reply to this email directly, view it on GitHub https://github.com/usebruno/bruno/issues/1306#issuecomment-1880611923, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEIIC3KHYW3BRP4VGBPA23YNOZLHAVCNFSM6AAAAABBKAWQAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGYYTCOJSGM . You are receiving this because you were mentioned.Message ID: @.***>