Help wanted: more contributors

[dphang]

Hi all,

I hope you had a good 2021 so far! We are nearing the release of 1.19 which has path-based locales support, image optimization, experimental CDK support, versioned static pages, much better e2e test coverage, among other improvements and bug fixes. A few more fixes and testing and I think it should be good to go to release it in the next couple of weeks. Thanks to all who have contributed in one way or another, such as by reporting bugs, helping alpha test, or made a financial contribution.

As mentioned in this issue: #777, I kind of gave a roadmap of where we wanted this project to go in the future. Basically, right now everything is tied to Lambda@Edge but we want it to be more platform-agnostic so it's not limited to AWS Lambda@Edge. Additionally, we want to improve the developer experience by making it easier and more configurable when deploying (e.g CDK) and upgrading the current frameworks (e.g Serverless).

Unfortunately, things have been a bit slow as I have had less time than expected (due to job and personal reasons) and I have also been the only core contributor for the past few months. So in 2021, I've only been able to deliver most of the Next.js 10 features and some of bug fixes so far. Since we've been growing (nearly 2k stars!), to ensure this project continues to be successful, I am looking for another core contributor and potentially more other contributors in smaller areas.

These are the specific areas I have in mind to work on:

• Serverless Core: work on Next.js features, core handler function code that is to be run on serverless platforms (AWS, Azure, GCP, etc.) in a platform-agnostic way. This will require refactoring the Lambda@Edge code from the actual Serverless code. Note, I am working on this area next myself. Of course, if interested feel free to let me know.
• Infrastructure/DevTools: how to deploy the code (via CDK, Terraform, etc.) and improve the developer experience in configuring it. In particular, we want to make it easy to use by giving pre-configured deployment scripts, but also give users more flexibility in configuring their own IaC. Right now, everything is done through this component and we have to manually maintain/add new ways to configure things. Even things like teardown of the component is not fully automated due to CloudFront taking time to delete a distribution. There is experimental CDK support, we would love to continue improving in this area.
• Serverless Framework upgrade: related to infrastructure or dev tools, this can be part of the above area or can be its own independent project. It has been quite overdue. Note, I believe there is a USD $1000+ from Serverless for doing this upgrade which we can claim - so hopefully could be an incentive for someone more familiar in this area.
• Platform plugin owners: for example, once we've made the core code platform-agnostic, we need people who are experts or users in other platforms like Azure/GCP/Lambda/Cloudflare Workers who would like to try to make this component work on there, or at least investigate how to. Personally, I will continue to maintain the Lambda@Edge implementation as I come from an Amazon/AWS background and will continue to use it this way. Note, for now this will be mostly investigative, as the platform-agnostic core is a requirement to start work on these.

There are also some smaller areas good if you want to contribute but not be a core contributor yet (but room to grow here, depending on your interest):

• Implement some missing features: we've tried to implement the majority of features but there are some that are missing features like: (a) cross-rewrites, e.g you are rewriting from default lambda <-> API lambda - which won't work. (b) Incremental static regeneration (this may require some spinning up new backend components like SQS + Lambda to trigger the page regeneration etc.), among others.
• Performance optimizations: for example, I know of a couple areas that could be improved just in the Lambda@Edge handlers: (1) the image optimizer lambda is not fully optimized - (a) its dependencies are not automatically upgraded nor bundled into a single Lambda function, and (b) there may be ways to avoid hitting S3 unnecessarily, e.g by bundling image files themselves into the Lambda or some other caching. (2) Lambda@Edge static pages / assets may be slow to retrieve from S3 because of having two Lambda@Edge handler setup (origin request, and origin response). There may be ways to improve performance by using a single origin request handler (which itself makes requests to S3) and also store static pages and/or assets in the Lambda itself.
• CI/CD and Testing: we have good e2e test coverage for the component right now, but some things can be improved. For example (a) fix the AWS throttling issue when too many e2e tests are run at the same time (I think AWS rate limit was requested), (b) add Windows / Mac workflows to test the code on other platforms.
• Triaging issues, work on bug fixes and small feature requests: this could be a good way to get your feet wet and learn more about this component. Currently, there are 100+ issues that should be cleaned up, and some of them might be straightforward to fix. There are also a few "good first issues" which means they might just need a small investment to look at.

If there's something else you're interested in, feel free to comment as well. We'd be happy to add you to our Slack. Thanks for your time!

[dphang]

FYI, there is a $2000 bounty from another community member on this issue: #804 for Incremental static regeneration. I don't have the time myself for this right now as I'm working on the long-awaited 1.19 release (not really needing the bounty myself).

If someone is interested, please let us know and we could work out details with all involved parties (probably over our Slack).

[adamdottv]

@dphang I may be interested in becoming an active contributor, but I do have some bandwidth limitations in the near term (hence the bounty on ISR support). Unfortunately, I don't have any expertise outside of AWS, so I may not be best suited to pushing on the multi-cloud effort. But, I do have expertise in AWS and could certainly help push the needle on that front.

I built an OSS CLI tool for deploying sites (including Next.js) into AWS accounts as a free Vercel alternative, and it depends on this project. I'm highly motivated to see this project succeed and improve in all facets (performance, security, feature parity, etc.).

[dphang]

@adamelmore great! We definitely could use more contributors. No worries, I'm also mostly familiar with AWS... but there are some improvements there too like supporting regular Lambda once again. If you want, let me know a good way to contact you and I can send you an invite to the Slack.

[adamdottv]

@adamelmore great! We definitely could use more contributors. No worries, I'm also mostly familiar with AWS... but there are some improvements there too like supporting regular Lambda once again. If you want, let me know a good way to contact you and I can send you an invite to the Slack.

You can email me at adam@elmore.dev

[dphang]

adam@elmore.dev

Thanks, invited!

[japrozs]

Hi, I would like to become a contributor to this project. Can you please send me a contributor invite and I could make some solid PRs

[dphang]

@japrozs great, thanks for your interest! Please send an email to serverlessnextjs@gmail.com with your email address you want to be added to and I can send you an invite to our Slack. Feel free message there if you have any ideas or pick up any of the existing issues (let me know if you and make a PR.

There is a list here of some missing (minor) features: #1127, for example.

[slawekkolodziej]

@dphang I can try to find some time to contribute too! I'll send you an email to the address above too

[dphang]

Thanks all.

Also some other areas to look at:

• Updating docs: the old doc site is outdated and everything is currently cramped in the main README. Will need things like architecture docs, debugging, configuration, etc.
• Logging: logging both at build and run time - can be improved especially allowing verbose logs. Since we have Rollup.js, I think we can also do interesting things like do a 2nd rollup and remove these verbose log lines from the code itself per a setting

[J3tto]

@dphang - Happy to contribute where I can.

james@stackcrafters.com

[mayank-budhiraja]

@dphang I am interested in contributing to the repo.

[dphang]

@mayank-budhiraja yes feel free to send an email to serverlessnextjs@gmail.com to get added to the slack and also work on issues tagged "Good first issue"

[markronquillo]

same here I would like to contribute!