Questions about vercel as UI for industrial machine monitor

[Elindo586]

Summary

So I want to record and monitor an industial machine using a controller to send machine's condition information to the cloud, and display it on a website.

Could Vercel and Next.js do the job? If so, what would be the best way??

I am thinking:

1. Create code for controller and send a signal via http / api to a back end.

2. Backend using vercel / next.js .. get the signal from a controller ... forward data to a database, postgress?

3. At the same time I send data to the database I could send it to the front end.

4. I could display current data on the front end.

5. If desired I could also display some history data using the database..

Has anybody worked on similar projects before? Is this a typical type of situation?

Also.. if the data from monitoring changes every second, then, wouldn't the database collection get so big and expensive???

Could vercel be fast enough to keep collecting data this way??

Additional information

No response

Example

No response

[xabierlameiro]

Hello! Your industrial monitoring project is definitely feasible with Next.js and Vercel. According to the official documentation, here are the important technical considerations:

✅ What IS possible:

API Routes to receive data

Next.js App Router supports Route Handlers that can handle HTTP POST requests from your controller:

// app/api/machine-data/route.ts
export async function POST(request: Request) {
  const data = await request.json()
  // Process controller data
  return Response.json({ success: true })
}

Official Vercel Functions limitations:

• Maximum duration: 60s (Hobby), 800s (Pro/Enterprise with Fluid Compute).
• Memory**: Up to 3009 MB (Pro/Enterprise)
• Payload**: Maximum 4.5 MB per request
• Concurrency**: Auto-scales up to 30,000 simultaneous requests

⚠️ Important considerations for data every second: **## 1.

1. Cost and scalability

With data every second (86,400 requests/day), the cost can increase significantly as Vercel charges by wall-clock time.

2. Recommended alternatives for high frequency: ** Batch processing: Send multiple requests per second (86,400 requests/day).

• Batch processing**: Send multiple measurements in a single request.
• Edge Functions**: For more efficient processing.
• Self-hosting**: For full control over resources (official documentation)

3. Optimised database

For 86,400+ daily records, consider:

• Time-series databases (InfluxDB, TimescaleDB)
• Data retention policies
• Aggregations by periods (minutes, hours)

🏗️ Recommended architecture: **

Controller → API path → Time series DB → Dashboard
                    ↓
              WebSocket/SSE for real time

For real time on the frontend:

• Events sent by the server (SSE)
• WebSocket connections
• Streaming responses

📚 Official resources:

• Next.js deployment](https://nextjs.org/docs/app/getting-started/deploying)
• Route handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers)
• Vercel feature limitations](https://vercel.com/docs/functions/limitations)

Can I help you with any specific aspects of the implementation?

[Elindo586]

Thank you!

Ok wait... you just reminded me of functions timing out in vercel... I think I had a problem with that before, but somehow apparently I don't anymore.... hmm.. maybe it was because I wanted to do a cron job and it was timing out, but then I took the job out of the cron job..

When do I have to worry about a function timing out?

Currently I have another program running every 10 seconds, lasting for a few hours at a time without a problem...

[icyJoseph]

I think here you have to establish some design guidelines first.

• what is the purpose of this view? to allow remote monitoring? local?
• how will this data be viewed? Show the last 30 minutes? 7 days? 90 days? of each second tick? Allow users to change the view spans?
• Is latency important? Jumping from your controller (a PLC?) to a proxy endpoint, which in turn forwards that to your db, implies 2 HTTP round trips, which under the right conditions, can add to 200-300ms if not more, and the notifying the client and having them download the new data entry could also add another 100ms, suddenly, we are lagging behind the real data. For some industrial processes, this might be way too much, for others, insignificant.
• what kind of budget do you have, what kind of safeguards, failsafes, budget limiters do you need to have in place? For example, doing about 90k post requests and have clients query major chunks of data, while also polling, could very quickly drain your budget.
• does it make sense to eventually store some of this data in Blobs/Objects? and for historic views, load those instead?

You should probably solve one issue at a time. Let's say, for example, you could start with your PLC controller somehow running the database client you choose, or is already networked with a computer, and that computer can listen on the bus, and then post that data to your DB. Make sure to isolate this connection, with proper auth setup, and such.

Verify data integrity and such, typically these DBs have dashboard where you can see the tables, etc. How much space in the db are consuming with your writes?

Now you can spin up a Next.js project, integrate with that DB and subscribe to changes. See how that works out with one client. Is it consuming resources way too fast?

With this info, for example, you could figure out that you can save to a static file past data, say older than 4 hours, so if someone wants to see that, you can load a static file, which is pretty cheap, and only recent data queries would hit the DB.

There are other ways to think about this too, but it depends on what your actual use case details are. Are you just interested in giving this controller a UI? Maybe that, but also, store the data recorded for later inspection?

When do I have to worry about a function timing out?

That's per request. A request shouldn't run for more than the timeout, or it will be terminated by the environment. If you are doing a small workload on every request, then you should probably worry instead about the "invokations" limit.

[xabierlameiro]

Great follow-up question! Based on the official Vercel documentation, here are the exact timeout limits you need to consider:

🕐 When functions timeout (official limits):

Serverless Functions:

• Hobby plan: Default 10s, maximum 60s
• Pro plan: Default 15s, maximum 300s (5 minutes)
• Enterprise: Default 15s, maximum 900s (15 minutes)

With Fluid Compute enabled:

• Hobby: 60s (both default and maximum)
• Pro/Enterprise: Default 90s, maximum 800s (~13 minutes)

Edge Functions:

• Must send initial response within 25 seconds
• Can run indefinitely after that

✅ Your current setup (every 10 seconds):

Since your program runs every 10 seconds for hours, you are likely using:

1. Cron jobs or external scheduler
2. Quick API calls that complete well under the timeout limits
3. Possibly Edge Functions (which are perfect for this pattern)

⚠️ When to worry about timeouts:

You WILL timeout if:

• Single request takes longer than your plan maximum duration
• Database queries are too slow
• External API calls hang
• Heavy computational tasks exceed limits

You WILL NOT timeout if:

• Each individual request completes quickly (< 10s for most plans)
• You are using efficient database connections
• External APIs respond promptly

🔧 Configuration example:

// For longer processing if needed
export const maxDuration = 30; // seconds

export async function POST(request: Request) {
  // Your 10-second interval logic here
  return Response.json({ success: true });
}

💡 Recommendations for your use case:

1. Monitor function duration in Vercel dashboard
2. Consider Edge Functions if processing is lightweight
3. Implement error handling for timeout scenarios
4. Use streaming responses for real-time updates

📚 Official sources:

• Function Duration Limits
• Configuring Duration
• Edge Runtime Limits

Your current pattern sounds optimal for Vercel! Are you experiencing any specific timeout issues, or is this more of a preventive question?