DEV Community


DPS911 Blog #9: Services, Services, Services

hyperthd profile image Abdulbasid Guled ・3 min read

Cause my blog titles are very long apparently and they're causing a bug. Well, hopefully, this is short enough for you!

So after the debacle that was the Post microservice, I've finally been freed to work on some other stuff. So what was the first thing I did? I went right back to the posts microservice of course.

You can find that PR here. This PR addressed moving the posts microservice over to the frontend. This required me to make the posts url an argument in the Telescope Dockerfile so that it can be passed. This is because Telescope uses different urls for the services depending on whether the frontend is being built in development, staging, or production mode. Fun Fact: My boi Royce's PR was failing to load any posts in his PR's deployment because I forgot to change the SearchResults.tsx page to use the new posts service. A funny catch from today's meeting that I found.

From there, it was simply a matter of putting the posts service url inside the next.config.js file, exporting it inside the config.ts file, then using that in place of the TelescopeURL wherever it was used. An unfortunate side-effect of this was that I had to reintroduce feeds back into the posts microservice because they were needed in some of the posts related components. I'm sure they can be removed at some point, but it's a matter of when and how.

I also worked on modifying our base jest.setup.js to import the development env files. You can find that PR here. This involved removing the jest.setup.js files from any microservice folder since those were only there to pull the env file and I did so in the base jest.setup.js file. I kept the one inside the posts service to import the MOCK_REDIS value, but I might take that out because it gets added in the jest scripts. I'll need to work on that a little.

I worked on some other PRs this week as well. Here's a list of the following PRs that I reviewed:

I also did research on possible ways to incorporate private and public keys into our jwt authentication. These would be used to sign payloads, making them more secure as opposed to using a secret from the env. This would also be something that the staging and production endpoints can take advantage of. I'm currently working on this with Yuan and Ilya, and hope to have a PR for this soon. This would also be incorporated into Satellite, making it even easier. I'll have more to report on this next week, hopefully.

Next time, ver 1.9 releases. I was assigned to continue work on the search microservice that Ray started due to him being stuck up on his work. Juggling that with jwt auth related stuff will be tough, but definitely doable. Until then, stay tuned!

Discussion (0)

Editor guide