Config overrides

[AhmadBarake]

Hello, firstly, great work on this project, very interesting!

I had a question relating to communication between the h5p-server and h5p-client (our implementation is in reactjs) , this may seem trivial but any help would be appreciated!

I was wondering if perhaps I could get more clarity on how to override values using config as mentioned in the docs. (https://docs.lumi.education/usage/ajax-endpoints#configuring-custom-endpoint-routes).
our use case is as follows:

we're either going to have a separate h5p-server that works in parallel with our other NodeJS server, or (more likely) directly integrate the h5p-server into our existing node server.

if a config sample is available (besides the object mentioned in the docs) that would be great help also as I would be able to see how and where it's supposed to go!

[sr258]

Hi Ahmad, Sorry about my relatively late answer! I'm not entirely certain what you have in mind, but there is an example of a static configuration that we use in our Lumi desktop application here: https://github.com/Lumieducation/Lumi/blob/master/server/src/config/H5PConfig.ts#L13 <https://github.com/Lumieducation/Lumi/blob/master/server/src/config/H5PConfig.ts#L13> Here you can also see, how the various url parameters can be configured. Normally you can leave them as they are and you only have to change the baseUrl. If you want to have an independent H5P NodeJS server (microservice approach), you can do this by running the H5P microservice and your existing application behind a reverse proxy (e.g. NGINX) that gives the illusion to the client that everything running on one host. You configure the reverse proxy to route your H5P calls to the H5P microservice (/api/v1/h5p routed to h5p service) and the rest to your app server (e.g. /api/v1/yourroutes to your server). That way you can have separate servers but they all appear to be on one host. This is important as the editor won't function properly if h5p runs on a different host than the actual app (CORS issues). If you put everything into a monolith (one NodeJS app with your custom code and the H5P routes) the route configuration would be the same, but you don't have to use the reverse proxy. Note that some implementations use a H5P baseUrl of '' and then urls like ajaxUrl = '/api/v1/h5p/ajax' and contentFilesUrl = '/static/content'. The reason is that strictly speaking some of the routes that are covered by h5p-nodejs-library aren't API calls (getting content and library files mostly) and the routes can be a bit misleading. You can work around this by setting an empty baseUrl and full path urls for the urls which derive from baseUrl. I hope this has helped you out! Best Sebastian

…

Am 07.10.2021 um 22:05 schrieb Ahmad Barake ***@***.***>: Hello, firstly, great work on this project, very interesting! I had a question relating to communication between the h5p-server and h5p-client (our implementation is in reactjs) , this may seem trivial but any help would be appreciated! I was wondering if perhaps I could get more clarity on how to override values using config as mentioned in the docs. (https://docs.lumi.education/usage/ajax-endpoints#configuring-custom-endpoint-routes <https://docs.lumi.education/usage/ajax-endpoints#configuring-custom-endpoint-routes>). our use case is as follows: we're either going to have a separate h5p-server that works in parallel with our other NodeJS server, or (more likely) directly integrate the h5p-server into our existing node server. if a config sample is available (besides the object mentioned in the docs) that would be great help also as I would be able to see how and where it's supposed to go! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1815>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUPXBB2PHLA66XKHRNBSZLUFX4QNANCNFSM5FSCNHHQ>.

[AhmadBarake]

Hi Sebastian,

Thank you so much for the clarification, after reading your well-structured, highly detailed answer I believe we will go with a Monolithic approach after all, less maintenance hassle down the line.

Thanks again and keep up the great work !