-3

Thinking about non functional requirements (the -ities) and other concerns, which approach would you choose and why? consider the two snippets

Direct Supabase Connection

import { useState, useEffect } from "react"
import { createClient } from "@supabase/supabase-js"

export function GeneralTab() {
   const [topicList, setTopicList] = useState([])

   const fetchTopics = async () => {
      try {
         const supabase = createClient(process.env.SUPAURL,process.env.SUPAPUBLIC)
         const { data } = await supabase.from("topics").select('topic')
         setTopicList(data.map(item => item.topic))
      } catch (error) {
         console.error("Error fetching topics:", error)
      }
   }
   useEffect(() => {fetchTopics()}, [])
}

Microservice Connection

import { useState, useEffect } from "react"

export function GeneralTab() {
   const [topicList, setTopicList] = useState([])

   const fetchTopics = async () => {
      try {
         const response = await fetch("https://your-microservice-endpoint.com/topics")
         const data = await response.json()
         setTopicList(data.map(item => item.topic))
      } catch (error) {
         console.error("Error fetching topics:", error)
      }
   }
   useEffect(() => {fetchTopics()}, [])
}

Direct Supabase Connection

is simpler, faster to develop, and potentially has lower latency, but it exposes the API key and is less flexible.

Microservice Connection

offers better security, scalability, and flexibility but adds complexity and potential latency.

14
  • The question title and body seem to be asking different questions. One might be on topic. The other one is definitely opinion-based. Can you clarify what you are asking? Commented Sep 5 at 13:01
  • 1
    I see two down-votes and no close votes. Can we have a little patience, please? The OP just posted 15 minutes ago. Commented Sep 5 at 13:12
  • How do i prove which one is correct. Are there any metrics that are commonly accepted as proof. If I do not know the what the usage max will be for this functionality.
    – codemarc
    Commented Sep 5 at 13:36
  • 2
    @JimmyJames: "quick sort" is no objectively better than "bubble sort" (or vice versa). You need to define your criteria first and give them weight. Lets say my criteria here is *"I need a simple, easy to maintain sorting algorithm for 200 items at maximum which works in Excel VBA", and it needs to be just "fast enough" for my purpose". (I did not invent this to prove my point, I actually had this requirement a few years ago.) My point, however, is a different one: the wording of the question expresses an expectation about "mathematically strict, objective criteria" to decide ...
    – Doc Brown
    Commented Sep 5 at 21:00
  • 2
    This question is similar to: If there are two ways of approaching a task, how should one choose between them?. If you believe it’s different, please edit the question, make it clear how it’s different and/or how the answers on that question are not helpful for your problem.
    – Doc Brown
    Commented Sep 5 at 21:08

2 Answers 2

3

simpler, faster to develop

Do this first, provided it doesn't stop you from switching.

better security, scalability, and flexibility

Are all nice things to have provided you get them done before going out of business.

but adds complexity and potential latency

Which will be easier to judge the impact of when you have something to compare it to.

2

but it exposes the API key

You have to evaluate the risks and accept them both as a business and personally.

If something goes wrong:

  1. Do you accept the potential financial loss?
  2. Are you going to jail?

The real problem here is not knowing what the risks are. If you don't know then you can't accept them, and should just follow best practice.

Frankly though are you actually forced to make this kind of choice? what's it gonna take you a couple of extra days to make an API and add some out the box auth?

Not the answer you're looking for? Browse other questions tagged or ask your own question.