https://github.com/adonese/noebs/blob/509eb98291e4bd67ddf1aa9dcca3e85bba389c91/utils/helpers.go#L18-L18

api gateway has the worst functionality ever. the code is getting really terrible and it needs to be refactored

Dependabot couldn't find a go.mod for this project.

Dependabot requires a go.mod to evaluate your project's current Go dependencies. It had expected to find one at the path: /go.mod.

If this isn't a Go project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

currently our apigateway only supports jwt tokens, which while very well and served as pretty good on non browser clients, suck on the browser

This is important as it will help us in

• documenting our APIs. The same OpenAPI schema can be used to document the endpoint.
• it is really really nice though. Just do it.

https://github.com/adonese/noebs/blob/2d7a371f1677f19d1e19e713816d96cc19301f4f/consumer/payment_apis.go#L1134-L1134

Currently the response messages are really messy and I highly rely on HTTP response codes to indicate to the clients what went wrong. I don't like it this way.
For error messages, I'm thinking about this: {"error_code": some_error_code, "error_message": "some_error_message}. Know that this have many variants. For validation errors, it will be a list of error_code, error_message.

Also, what is the kind of errors are we having. I'm thinking of validation errors and ebs errors.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

github.com/ugorji/[email protected]: reading github.com/ugorji/go/go.mod at revision v1.1.5-pre: unknown revision v1.1.5-pre

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

To make the mocking server works, we need to modify the logic in our handlers in this way:

var res EBSResponse

=>

var res *EBSResponse

that way we will make sure to update the pointer not a new copy.
In EBSHTTPClient, we actually use a pointer receiver now.

Dependabot can't resolve your Go dependency files.

As a result, Dependabot couldn't update your dependencies.

The error Dependabot encountered was:

github.com/ugorji/go/[email protected]: reading github.com/ugorji/go/codec/codec/go.mod at revision codec/v1.1.5-pre: unknown revision codec/v1.1.5-pre

If you think the above is an error on Dependabot's side please don't hesitate to get in touch - we'll do whatever we can to fix it.

View the update logs.

services here mean all of our http.Handler endpoints. Currently, they include:

• *redis.Client
• *db.DB
• log.Logger

The power of struct embedding is that we can keep on adding new fields without degrading the code quality, and keeping all layers easily separable.

Well, this might be very simple since gin can be easily configured to achieve that.

The idea is that we want to encourage our clients to use our middleware! Even if they don't have access to the source code.

Required changes:

• change the response to be EBS compatible
• change the url to map into EBS service names as well

Proposed solution:

• use http header X-Resource-Use-EBS to indicate that the client needs their urls EBS response.

Problems:

• the problem with the proposed solution is that we must also change the endpoints names to map into EBS such that we achieve a 100% smooth transition.

hello ,
i try test this system on my local machine
so i see this missing:
package noebs/dashboard
and noebs/validations
in .gitignore you put noebs file or package

I am not an expert in this language (gO lANG).

may can you writ some documentation :) 👍

This is a very must! I have to get my head into this and start seriously documenting the API.

This function needs to be enhanced in terms of documentations and naming as well

https://github.com/adonese/noebs/blob/d4ff5286afb13160c387ab55be6779c93d28ff79/apigateway/jwt_auth.go#L85

We have different layers in noebs, and it is very wise that each one of them should be isolated from the others:

• merchant apis
• consumer apis
• merchant dashboard
• consumer user's services
  that will allow for smooth and safe deployment for these layers, as a change in consumer services, should not trigger a whole system build.

also, it is evident that the development on dashboard and consumer services will be more active than in the payment ones.

Dependabot couldn't find a go.mod for this project.

Dependabot requires a go.mod to evaluate your project's current Go dependencies. It had expected to find one at the path: /go.mod.

If this isn't a Go project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Dependabot couldn't find a go.mod for this project.

Dependabot requires a go.mod to evaluate your project's current Go dependencies. It had expected to find one at the path: /go.mod.

If this isn't a Go project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Low test coverage as a symptom of tight coupling

I noticed that the test coverage is quite low on this project, which may not be a massive problem early on - but can have a massive impact on how maintainable the project will be long term. Without tests it's very hard add new features/refactor with any degree of confidence that they will work/not break existing functionality.

I suspect that one of the reasons that there is currently low test coverage is that the project is currently difficult to test, such as below, where the redisClient is being pulled into the function:

https://github.com/adonese/noebs/blob/34343c571d8d473e26d0f358b426920b93076ddf/cards/cards.go#L180

A Suggestion

Decoupling your domain layer from external infrastructure makes it easier to test your application. Your core code shouldn't care if the data is being stored on Redis, Postgres, Cassandra, or even in memory on the same instance - it should be easy to swap in different storage drivers. This makes it easier to test with an in memory database, and gives you the flexibility to one day move away from Redis, if for example Redis can no longer support the volume of traffic your application handles.

Some great resources that helped me to understand this better:

• https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
• https://softwarecampament.wordpress.com/portsadapters/

Interfaces in Golang are very useful for accomplishing this looser coupling

• https://tour.golang.org/methods/9
• https://deliveroo.engineering/2019/05/17/testing-go-services-using-interfaces.html

A well designed, well tested application can also increase trust in a project, helping to drive adoption. I hope this is useful - and it goes without saying that time permitting I'm happy to help.

The response of not found is like this:
{code: not_found, message: true}

Which is awkward and not the design intended at all.

https://github.com/adonese/noebs/blob/d4ff5286afb13160c387ab55be6779c93d28ff79/apigateway/main.go#L109

We better made an internal service that always checks EBS status and accordingly:

• either change dns (api.noebs.dev, beta.noebs.dev)
• or configure nginx to load balance betwee api.noebs.dev, beta.noebs.dev

In #26, the suggestion was to loosen the coupling between the system components, as that will help in testing.

One of the core issues related to #26 is that there is no clear distinction between noebs the library and the implementation. We must give our users interfaces for noebs functionalities.

• move any of the functionalities that is used in our routers into exported functions (so that others, who don't want our implementation to use these helper functions)
• slowly move ebs_service and the rest of main functions into a new package (preferably outside of noebs package)
• noebs should be a package and all of its implicit toolings and magics be exposed to other uses

This decoupling will:

• make testing noebs-the-library more easier
• delegate testing the routes to the implementer
• the only untestable part will be in EBSClient

We need to use a proxy server. it will help us in:

• handling SSL certificate
• handling static files
• proxying to different instances running as we want to add another EBS compatible layer

it makes perfect sense to send a user's message on card transfer request. This should also not change the payment api itself--the payment api needs to be completely isolated from this logic.

APIs affected

This will affect consumer api only; nothing needs to be changed for the merchant.

Proposed solution

TODO

We often need to figure out the mobile number service provider, we use heuristics such as the prefix to figure out what it is.

This service will be built on top of cashqbot mobile guesser, but we will need to add:

• a service to check for relevant ebs response (wrong biller, wrong service provider, etc check ebs docs)
• this service will first use the prefix (from cashqbot implementation), and given the response it will refine its results
• this service could be done in our microservices code, not noebs

https://github.com/adonese/noebs/blob/0d33246d2781ad314774a726fc9e44e247c5fa05/consumer/payment_apis.go#L1138-L1138

as we are having our mail service now, it makes since to develop the password reset api

*redis.Client is thread safe and therefore can be used concurrently by multiple goroutines. We are currently using different clients and it seems to be not the right way of doing it. redis/go-redis#23

a very awaited feature is to add chat support for our cashq. it will help in many regards, but it is really just a nice feature to have a chat enabled in our platforms.

Dependabot couldn't find a go.mod for this project.

Dependabot requires a go.mod to evaluate your project's current Go dependencies. It had expected to find one at the path: /go.mod.

If this isn't a Go project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Instead of Copying the incoming request stream into two different buffers, it is more efficient and just the correct way.
The request body will eventually transferred into many middlewares and different layers.
stream of request -> validator -> ebs_gateway -> response -> logger -> db? -> sms_gateway, and perhaps through different services.

ID is really just a unique id we assign to each transaction for each payeer. We need to inquire for the fully qualified UUID. Since each payeer will have different ids.

payee_id_key: set(ids)
payee = get_payee_key(id)
url = get_url_for_payee(payee)

And return it in the billerForm struct