Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(remix): Add Fastify server adapter #11261

Open
wants to merge 32 commits into
base: develop
Choose a base branch
from

Conversation

rustworthy
Copy link

@rustworthy rustworthy commented Mar 23, 2024

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

  • If you've added code that should be tested, please add tests.
  • Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

@mydea
Copy link
Member

mydea commented Mar 25, 2024

Hello, thank you for this PR!

Actually, I wonder if we need this at all in v8 - there, we auto-instrument fastify & express under the hood, so maybe we can get rid of this actually 🤔 needs some more testing though, I guess - any thoughts @onurtemizkan & @AbhiPrasad ? I am not so familiar with Remix systems and how these parts work together...!

@rustworthy
Copy link
Author

Hello, thank you for this PR!

Actually, I wonder if we need this at all in v8 - there, we auto-instrument fastify & express under the hood, so maybe we can get rid of this actually 🤔 needs some more testing though, I guess - any thoughts @onurtemizkan & @AbhiPrasad ? I am not so familiar with Remix systems and how these parts work together...!

My pleasure! I am now setting up things for e2e manual test. As for the wrapper itself, what I have learned so far from the codebase, we need to know ahead of time how to parse out details from the request data. We also need to know the name of the response's end method, to flush the data to remote repo prior to resolving

Copy link
Collaborator

@onurtemizkan onurtemizkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @rustworthy. Looks good to me generally. Could you rebase and add e2e tests please?

@onurtemizkan
Copy link
Collaborator

Actually, I wonder if we need this at all in v8 - there, we auto-instrument fastify & express under the hood, so maybe we can get rid of this actually 🤔 needs some more testing though, I guess - any thoughts @onurtemizkan & @AbhiPrasad ? I am not so familiar with Remix systems and how these parts work together...!

@mydea, yes I was also curious about it, had some trials to remove adapters, but looks like we need to keep those for the time being.

@rustworthy rustworthy force-pushed the feat/remix-fastify-adapter branch 2 times, most recently from 03f49b6 to 1806704 Compare April 6, 2024 06:01
"@mcansh/remix-fastify": "^3.2.2",
"@remix-run/express": "1.17.0",
"@remix-run/node": "1.17.0",
"@remix-run/react": "1.17.0",
"@remix-run/serve": "1.17.0",
"@sentry/remix": "file:../..",
"express": "^4.19.2",
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggesting to have express explicitly listed as a dependency in this package. The fact that the upper level dev package is powered by express may not be true in the future. Plus it makes it clear, adapters for which frameworks are being covered here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense to me 👍

"@types/express": "^4.17.14"
"@types/express": "^4.17.14",
"fastify": "^4.26.2",
"typescript": "^5.4.4"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully we can use latest tsc for the package. Otherwise, it's typing the exported wrapper for fastify is problematic, since the compiler is not sure that the handler is acually a RouteMethodHandler which it is.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can loosely type our exported wrapper instead of bumping the TS version. We apply TS version updates to all packages together when we do.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I did not know there was a policy or convention with regard to tsc used. As for loosely typing, that will mean they will need to assert like as RouteMethodHandler that somehow seems not that ergonomic, but if it's a common (or at leas acceptable) practice, let's put it this way. Btw, the only reason the fastify package has been added - is to type the handler, we are otherwise good, since the internals of the request have already been described in the polimorphic request types definitions.

const requestHandlerFactory =
adapter === 'express' ? wrapExpressCreateRequestHandler(createRequestHandler) : createRequestHandler;
const adapters = {
[Adapter.Builtin]: createExpressRequestHandler,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

built-in is actually a createRequestHandler from @remix-run/express. Does this mean it actually does not need a wrapper?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we're auto-instrumenting the built-in createRequestHandler from @remix-run/node. So this doesn't need a wrapper for built-in tests.

@onurtemizkan onurtemizkan changed the title Remix fastify server adapter feat(remix): Add Fastify server adapter Apr 8, 2024
Copy link
Collaborator

@onurtemizkan onurtemizkan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few comments about the TS version and testing, but overall looks good to me.

@@ -5,6 +5,7 @@

"compilerOptions": {
"jsx": "react",
"module": "es2020"
"module": "es2020",
"ignoreDeprecations": "5.0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We won't need this unless we update the TS version right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's right, and that commit has been reverted

@@ -7,11 +7,15 @@
"start": "remix-serve build"
},
"dependencies": {
"@fastify/formbody": "^7.4.0",
"@mcansh/remix-fastify": "^3.2.2",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is breaking the tests on Node 14 / 16.
I'd suggest adding an e2e test application under dev-packages/e2e-tests/test-applications for Fastify where we can control the environment better and also can test more extensively, instead of adding it to the integration test matrix.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I've added an app with remix-express-vite template with the idea to update it to use fastify engine and add e2e tests. This is embarrassing but I cannot make the app I've added resolve the local @sentry/remix correctly, and so cannot navigate around the test app routes, neither build it. Moreover, I am having hard times with running the test app that's already there - the create-remix-app-express-vite-dev: there's a proxy there, some customization in .npmrc and also pnpm manager mentions in the package.json . You can imagine, my first try was to cp -r the mentioned app and update where necessary, but I just failed to install the deps 🥲

Can you please assist in setting up the test app, but only in the scope of making the local copy of @sentry/remix (where the fastify wrapper is already included in the build) resolve correctly? I would have looked up the solution from another test app but seems like all them are using the latest npm copy of the lib. I'll then add the fastify framework and e2e tests myself.

If you pull the branch, and run npm run dev from inside the newly added dev-packages/e2e-tests/test-applications/create-remix-app-fastify-vite app, and visit the index page, you will see the error and maybe immediately know the answer.

Again, I am super embarrassed I need to ask for assistance here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rustworthy, not at all! Been there 😅

There may be a couple of reasons for this local resolution issue, but the steps I use are as below:

  • yarn build:tarball the whole monorepo.
  • pnpm store prune to make sure the latest tarball is published to the test registry.
  • yarn test:e2e or yarn test:run <test-app-name> to run the tests.

I'll pull the branch locally and test, do you mind if I push commits to this branch if needed, to save you time?

Thanks a lot for sticking with this! ❤️

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please feel free to push onto this branch directly and thanks for giving a hand here!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rustworthy, I have set up the e2e test application for you, there seem to be failing cases, you can run tests as I mentioned above.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onurtemizkan Thanks again for your help! I should have paid more attention to the right tools management (volta) and the proxy-registry trick. Added a trouble-shooting section to e2e-tests/README.md (maybe for myself in the future 😅 ).

As for the test app, I am now on it and planning to do the following:

  • add missing standard front-end tests and also back-end tests and make sure they are passing with express and the existing wrapExpressCreateRequestHandler;
  • switch to fastify with the corresponding wrapFastifyCreateRequestHandler and make sure tests are still passing.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just an update: in progress

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onurtemizkan Please have a look

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the tsc is not happy in remix integration tests - I'll fix this.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@onurtemizkan onurtemizkan self-assigned this Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants