Running Medusa from an existing Express application? | Medusa Community | Page 1

slender vale Nov 24, 2022, 7:31 PM

#

Hi all, I'm a new (prospective) Medusa user and (potential) contributor. Have got many years of enterprise ecom experience, and was pleased to come across Medusa several days ago in researching OSS headless commerce options.

I'm curious if anyone is running Medusa from within an existing NodeJs/ExpressJs application, as that happens to be my existing API stack. I would prefer not to make network calls across two Heroku apps – it'd be great if Medusa could expose its routes from within my existing API deployment, and share the same Redis and Postgres instances I already have.

I've had a look at some of the source code:

https://github.com/medusajs/medusa/blob/master/packages/medusa/src/api/index.js

And can see that the default exports are regular ExpressJs routers.

Is it possible to import these routers from within an existing ExpressJs app directly, instead of running a completely separate Medusa instance?

Alternatively, I might be able to serve my use case by calling Medusa services directly:

import { ProductService } from '@medusajs/medusa'

const productService = new ProductService()

productService.create(...options)

However, I'm not sure how to go about populating the injected dependencies required to initialise a new ProductService instance.

Cheers!

tulip canyon Nov 24, 2022, 10:00 PM

#

Hey there, it is not possible straight away but something you could try would be that in your existing project you import the index loader, first you create your express instance and then pass it to the index loader from medusa along the other arguments, after this loader you do what you already have in your entry point. One thing to add to your existing end points would be the cors and auth middleware (the admin or customer depending on the route domain) and you should be able to access the container in your route through req.scope like in medusa.

#

Basically your routes would act like any plugin or customizations. If you want your services etc to be part of the container you can register them using the container which is returned by the loader. Hope that it makes sense

slender vale Nov 25, 2022, 3:20 PM

#

Thanks @tulip canyon for a detailed response!

I was able to get the basics working for my use case, although it did take about half a day.

A follow-up question: is it possible to modify the naming of tables/columns created by Medusa? At the very least, it would be nice to be able to prefix the table names, as tables like user clash with my existing tables. It'd also be nice to be able to modify the column names, as the mix of camel and snake case implemented in Medusa is quite strange.

Edit: Seems as though the issue linked below is somewhat related.

https://github.com/medusajs/medusa/issues/769

tulip canyon Nov 25, 2022, 3:31 PM

#

Nice to hear, it is not possible to change the tables name in medusa unfortunately. The problem here is that you would like to keep both your tables and the ones medusa is creating, could you elaborate the purpose of this choice? They also probably have a different schema which will not work for medusa

slender vale Nov 25, 2022, 3:43 PM

#

What I'm attempting to do, from a high level, is integrate Medusa within my existing application.

I don't have any interest/need for any of the Store or Admin API endpoints. I only want to use Medusa as a backend commerce engine, to handle the heavy lifting.

All I want to be able to do is call various methods like productService.create and productService.retrieve in my backend business logic, where appropriate.

The setup I have now does achieve this, although it could use some polishing.

The final step is to clean up the db implementation.

I'm actually not seeing any schema clashes at all after running medusa migrations run (no seed data).

However, creating a separation of concerns is still crucial, and it'd be good to locate the Medusa tables under a separate schema from public.

Another option, of course, is to spin up a completely separate Postgres instance, but I'd rather not do that as it'd involve managing multiple dbs across multiple deployment environments.

I do believe issue 769 outlines the same concern/desire, and would be a critical issue for any existing production applications trying to integrate Medusa instead of running a separate standalone service.

tulip canyon Nov 25, 2022, 4:34 PM

#

I was thinking of something, but in fact it can't work. Even the services might try to access an entity fields that does not exists for you

#

I don't see how the services could be used in your app knowing that the tables and fields could be a lot different and there is no way to let know medusa about it

#

generally, people do a migration to medusa, they import what they have in there app, eventually doing a migration in multiple steps, I don't see how you could use a medusa service that is link to the medusa business logic under the hood and specific data type

slender vale Nov 25, 2022, 4:51 PM

#

Not sure I understand what you mean.

To be clear, I am perfectly find with the normal/existing Medusa tables and columns. If they cannot be renamed, that's fine.

I just want to be able to keep them in a separate schema, within the same db, so that our team can do direct joins.

#Running Medusa from an existing Express application?