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
@rustworthy
Copy link
Author

What's the destiny of this PR guys?

cc @onurtemizkan

@mydea
Copy link
Member

mydea commented Jun 3, 2024

I would think that with v8, where we have native support for fastify, this should not be necessary anymore...? Did you have the chance to try it out, so using @sentry/remix v8 out of the box, with no special fastify code?

@rustworthy
Copy link
Author

I would think that with v8, where we have native support for fastify, this should not be necessary anymore...? Did you have the chance to try it out, so using @sentry/remix v8 out of the box, with no special fastify code?

I think I got a déjà vu and it's super confusing 😕

I remember we agreed these changes were necessary, and we got them implemented and tested. If that's not needed in sentry@v8 why would we still have express specific test apps in the dev-packages? Should they be swapped for remix and remix-vite?

I am super ok if these changes are not needed, but can the maintainers then close this PR with a corresponding comment, so that we gracefully finish our work? Leaving it behind this way with no feedback is not super motivating for people to contribute to the project 😉

@mydea
Copy link
Member

mydea commented Jun 4, 2024

yeah sorry about this, I get that this is confusing, I am a bit confused myself 😅

@onurtemizkan recently opened a PR to use a new remix instrumentation: #12110

@onurtemizkan could you chime in if that PR would supersede/"fix" what this PR here has set out to do? Or if that will still be relevant?

@onurtemizkan
Copy link
Collaborator

Sorry for the late response @rustworthy and @mydea. I've been trying to recover from jet lag 😅.

Ideally, #12110 should make Fastify covered out of the box, like Express. That PR is the result of an experiment that turned out to work fine to replace the Express server adapter. So I would expect it to work for Fastify as well. Though, I did not have the bandwidth to test Fastify on that branch. We still may need a part of the updates in this PR (at least the new tests for sure), so I'd suggest keeping this PR open until we finalise #12110 and validate the Fastify usage if that makes sense to you guys. If everything goes well on that side, we can merge in the tests here.

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