Server blocks + load server functions

[trueadm]

A common pattern is to load data once on the server, what if we had this API that enabled it?

#server {

	// Is only run once on the server when the component is first rendered.
	// Can be used to fetch data or perform other server-side operations.
	export async function load({ params }) {
		return {
			message: await("Hello from the server!")
		};
	}
}


export component Foo(props, data) {
	// data is the object returned from the loadData function on the server.
}

The user would not be permitted to reference load in the client side code, it's purely server only.

Alternatively, it could be something like this? Where you return in the server block at the top level to populate the data

#server {

	// Is only run once on the server when the component is first rendered.
	return {
	  message: await("Hello from server")
	}
}


export component Foo(props, data) {
	// data is the object returned from the loadData function on the server.
}

The second one looks appealing but then we can't pass in things like params.

Then it got me thinking, it could be this?

#server {

	// Is only run once on the server when the component is first rendered.
	return async ({ params }) => {
	  message: await("Hello from server")
	})
}


export component Foo(props, data) {
	// data is the object returned from the loadData function on the server.
}

The other confusing part is that there can be multiple components in a module, so do they all get access to this data?

[leonidaz]

the way i thought it would work is by exporting a const with data:

e.g.

let saved_data: MyData;

#server {
  async function myFunc(): MyData { /* do async stuff to get data */ }

  if (!saved_data) {
    saved_data = await myFunc();
  }
  
  export {
    data: saved_data,
  }
}

and then you can use this or multiple of these in the components via #server.whatever and we would serialize it to the client and otherwise use on the server.

component A() {
  let data = #server.data;

  ... use it any way you like
}

and I assumed since the #server block runs on every request to the server, you can decide if you want to fetch it each time or save it via the module scope.

[leonidaz]

actually as per @trueadm , forgot that we're sandboxing the block:

saved_data shold not be visible to the server block
and should not be referencable at all
server blocks cannot see or access anything out of their block, by design

server blocks would receive params: context with request and app. And the app context could have a state where you can save data, perhaps even per component via using Ripple's Context. Just want to make sure to differentiate between request context vs app context, the former being per request and the latter for the running time of the app.

#server(context) {
  async function myFunc(): MyData { /* do async stuff to get data */ }

  if (!context.app.state.saved_data) {
    context.app.state.saved_data = await myFunc();
  }
  
  export {
    data: context.app.state.saved_data,
  }
}

[trueadm]

That doesn't feel very intuitive and means that code splitting won't work in the case where you don't reference the function or data. I'd prefer it if the sever block was side-effect free.

[Yusyuriv]

I think the first option would definitely confuse users who will want to name their functions load and wonder why it behaves weirdly and can't be referenced from components.

I like the last option the best, and I think it makes perfect sense that if several components are declared in the same file as a #server block, they all get access to that block. I assume it also lets the user define a named function so they can both return it here and also reference it on client side:

#server {
  async function doSomething(){
    return { ... };
  }

  return doSomething;
}

export component Foo(props, data) {
  // data is available here
  // but so is #server.doSomething() in case the user needs to update the data?
}

[trueadm]

Maybe it's as simple as constraining it to be this then?

#server {
  import { load } from 'ripple/server';

  const message = await load(({ params }) => "Hello from server");

  export {
    message
  };
}


export component Foo(prop) {
  let data = #server.message;
}

The constraint is that any top-level await calls in a server block must use load?

[leonidaz]

what are the constraints of the load function itself and its usage? You'd still need to run your own async code though?

[trueadm]

They'd function like SvelteKit's load function in that they'd run on request. Maybe load isn't the right thing. Maybe request is better?

#server {
  import { request } from 'ripple/server';

  const message = await request(({ params }) => "Hello from server");

  export {
    message
  };
}

[leonidaz]

I'm not sure I understand why people would need to run the request function vs just fetch directly (which we patch)? and we can provide any necessary context, params, etc. to the server block directly, e.g.

#server(context) { .... }

context would contain: request, request.params, app, router, router.routes, etc. we can figure out what we want to expose here.

[WebEferen]

They'd function like SvelteKit's load function in that they'd run on request. Maybe load isn't the right thing. Maybe request is better?

#server {
  import { request } from 'ripple/server';

  const message = await request(({ params }) => "Hello from server");

  export {
    message
  };
}

This is gonna be too hard for people to understand tbh.

[trueadm]

context would contain: request, request.params, app, router, router.routes, etc. we can figure out what we want to expose here.

I can get behind that:

#server(context) {
  import { load_title_from_db } from 'db';

  const title = await load_title_from_db(context.params);

  export {
    title
  };
}

Does make DCE a bit less clear though

[anubra266]

One question, what would be the recommended way to handle something like database connection pooling, as we woildn't want this to happen on every request.

// What you'd WANT: run once at startup, reuse pool forever
#server(context) {
    import { Pool } from 'pg';

    // This would run on EVERY request; completely wrong for pooling
    const pool = new Pool({ connectionString: process.env.DB_URL });

    const user = await pool.query('SELECT * FROM users WHERE id = $1', [context.params.id]);
    export { user };
}

[trueadm]

Yeah I don't think this approach scales. We need to keep server logic into functions, so for that reason I'm closing this idea thread.

[leonidaz]

One question, what would be the recommended way to handle something like database connection pooling, as we woildn't want this to happen on every request.

This could be an app level read-only state that would be a part of the context passed in to server blocks. And then they can use it to make requests. Where as the block would run on every server request.

I don't think this approach scales

Why wouldn't it scale? I think server blocks are amazing, we just gotta figure it out. I don't see a problem with doing the following:

#server(context) {
  import { load_title_from_db } from 'db';

  const title = await load_title_from_db(context.params);

  export {
    title
  };
}

component Print() {
  const title = #server.title;
}

• One of the things we could do is to prohibit imports. And you have to provide everything through context: the app state is read-only and people can place whatever functions they want in there through ripple.config.ts (e.g. middlewares, etc.)
• But I think the key feature here that has to be available is having data access on the server within components #server.data. It's totally under our compilation control and we can serialize the data to the client to have a common-sense hydration strategy.
• It actually works very nicely. If you export data from the block, you can use it on the server and it's serialized and hydrated on the client. If you export functions, they become rpc calls on the client. So you can't call exported function on the server directly, you have to export data.
• The whole context could be readonly and only expose the ripple controlled data (e.g. routes, url), no secrets) and functions provided via ripple.config.ts
• But no matter what we do we can't prevent people from leaking secrets. Maybe if we figure out the syntax with types that would help avoid it.
• We could make the block like a method, it already basically looks like a private class method and instead of exporting, the block has to return an object and so the return can be typed, e.g.:

interface ServerReturn {
  title: Title;
  load_stuff: (params: { id: number }) => Promise<Data>;
}

#server(context: Context): ServerReturn {
  import { load_title_from_db } from 'db';

  const title = await load_title_from_db(context.params);
  async function load_stuff(id: number) {
    // .....
  }

  return {
    title,
    load_stuff
  };
}

component Print() {
  const title = #server.title;
}

• Or maybe we also use export: export is only for rpc functions and return is only for data.

[trueadm]

I think server blocks are great, I just don't think you should be able to have control logic in the top level of them.