hampgoodwin / iata-finder Goto Github PK

I would like to get some more experience with CI/CD stuff but I/m not 100% sure on which service I want to use.

I'm mostly keen on this: https://concourse-ci.org/
because it's a chance to taken an open-source ci/cd (which I think is going to be popular) and deploy that, which will then deploy the app.

Here is a list of CI/CD tools we could use.
https://github.com/ligurio/awesome-ci

This could be part of make or in a bash script, or even in the readme.

This will be helpful since various contributors may need to generate code.

As part of #20, it will be good to have basic tests to make sure the server methods are functioning properly. These can be executed as part of the concourse (most likely) pipeline.

We have a current working branch which would make substantially large changes to the master branch. The branch is called "unit tests", but these tests will actually dial the server and depend on the dataservice, so they are not actually unit tests.

https://github.com/abelgoodwin1988/iata-finder/tree/add-unit-tests

Summary of changes so far:

• Code for creating the server has been moved to a separate server package.
• The server package contains a Create method which takes a reference to a dataservice and a config path. This allows us the ability to plugin a different dataservice or configuration file for testing versus that actual server (though for now they are the same)
• The create method returns a net.Listener and *grpc.Server which can then be user to start the server in main or testing functions.
• The grpc.Server is not "served" inside of the create function because doing so is blocking. We want this functionality when the actual server is running (for now, though there may be other options to make this work, such as waiting for a termination signal, etc.) . However, we need the server to be non-blocking in the tests.

@abelgoodwin1988, maybe take a look at the general structure as these are big changes. Would be glad to pair up sometime. For now, we can easily add more tests. The setup and teardown is pretty basic.

We have a bit of ugly code where we're parsing two different csv's based on two different data structs. Do we want to pull this out into their own handlers, or just leave as is until it gets more complicated (if it gets more complicated?).

https://github.com/abelgoodwin1988/iata-finder/blob/b0caa23b875f43653d9507b361d5b570c2e261c0/pkg/dataservice/dataservice.go#L85-L113

When we eventually get to charging for this for a higher request threshold we'll need some way to accept payment.

Also note; the actual server is going to stay open-source...
So maybe we should have a donation/patreon sort of thing in addition to a pay system for those who want to deploy this system for themselves?

Would this be a good opportunity to get some cloud api configs and create a terraform thingy so we can practice deploys?

The app is simple and it's containerized so we could focus on the actual standing up of infra instead of "getting things running" stuff.

We may want to get a token issuing system. I plan on deploying this and making it available for free for up to some number of requests a month (all data). For people who are going to be pounding the service I want them to cover the cost of using it. For this I want to get started creating a tokening system where a particular token is associated with a number of allowed requests and how many requests they're allowed.

I think this could be a good DB experiment; I would rather have the "requests made" field be auto incremented by a db trigger that auto increments that field whenever the token is accessed as a simple way to track # of hits a user has made..

Anyways this is something to think about..

I wonder if we should make this actually a separate micro-service? I think that is actually the right way to go, what are your thoughts?