Potential Pitfalls

This document will serve as a collection of areas that are high-risk and should be resolved as soon as possible

DockerHub

This is probably one of the weakest areas in our stack - dockerhub goes down fairly often, and we rely on it 100% to push new code. This could be resolved one or two ways, we could either set up a proxy cache of docker images that uses dockerhub as it's source (which would make our services more robust but not fix the underlying issue), or we could roll our own docker image repository (which would now put us in charge of maitenance, potentially increasing downtime).

Java gRPC+security

The java services use gRPC in a much different way than the go services. With the go services, the simpatra/x repository lets us update all gRPC clients and servers by simply bumping our internal library version, whereas our java services have the .proto files manually distributed, meaning they often get out of date quickly. This is also an issue when it comes to the security functions in java - once again we use simpatra/x for go but we do not have an equivalent for java, meaning all the security files need to be updated manually when anything changes.

The easy solution for this would be to simply finish migrating the services from java to go, but this is not recommended due to the fact that our java services are very critical and there are much easier things to do first.

The slightly more involved but still somewhat simple way to fix this would be to set up a private Java repository so that we could download the security package as a jar and utilize it in our services. Gitlab looks like it supports Java for private repositories, so that might be the way to go about that.

Shipping

Max Package Size

We are currently putting all of the items in a fulfillment into one package for shipping estimation. This causes issues due to the fact that both fedex and UPS have a 150lb limit to a single package, therefore any fulfillment that has more than 150lbs of product will error out. This is usually not an issue as almost 100% of what we sell on the marketplace is pellets which are down in the oz, but will need to be accounted for.

LTL

We currently do not support shipping of packages in pallets or in large enough quantities to call for LTL - it does loook like easypost supports it, but a rewrite of the shipping service might be necessary to work that logic in.

Product Accuracy

A very large issue that compounds the above issues is that a very large number of the products we have in the marketplace do not have proper weights listed. This means that some of our products (like for example single hypodermic needle) might weigh 10-20x it's value (1lb instead of 1oz). This is something that will be much easier to solve outside of code than through it

Hardcoded features

These are some features that are "done" but where implemented in a very hamfisted way to sacrifice code quality for velocity.

Loyalty points

While the loyalty service itself is very well written, the actual place in the order-service where points are awarded was built exclusively for the feature that was needed ASAP. Therefore the category that gives points is a hard coded value in the order constants file and the number of how much is redeemed is also hard coded. This could be an issue when "expanding" our loyalty offering, as there really isn't much else to expand, we would either need to double down on the hardcoded values or rewrite to a dynamic service

Free shipping

Free shipping is done on a per-vendor, hardcoded manner that simply checks if the order is with a specific vendor (string comparison) and contains a specific shipping method (string comparison) and then simply sets that value to $0

Referral codes

Almost all of the deals done through referall codes is hardcoded to the string value of the code. This includes the initial redemption and granting of the 5 free doses plan, all the way through what a user might see on the frontend.

Frontend State Management

As the scope of the project has grown, different state management patterns were implemented and refactors occurred when time allowed, but at this time best practices are not implemented across the board. In src/store, there are a mix of monolithic root modules, and smaller, more manageable, name-spaced modules. Future development should follow the namespaced pattern, and development that touches root modules should incorporate refactoring into the name-spaced pattern.

An example of the preferred pattern can be found by reviewing the marketplace namespace in src/store/marketplace. An example of a much more fragile pattern can be found in the root module at src/store/currentLocation. Until these modules are broken out into smaller feature-focused pieces, it will be difficult to introduce new functionality to current features without causing regression. It will be much easier to add testing to prevent this regression as well once these modules are broken out.

Simpatra Admin

Simpatra admin as a feature is fairly unstable, largely in part because a majority of the functionality was able to be quickly introduced as a side effect of the state management surrounding a users authenticated session combined with the simpatraAdmin user flag. When using Simpatra Admin within the context of a customer organization or location, state is not persisted across browser refreshes. To continue performing an action on an org/location context as simpatra admin it is important to re-enter the org through the UI flow of the simpatra admin dashboard so that the session state can build properly.

Currently, you can not successfully view marketing/analytics information while in context for an organization. This is because an organizations dosing users are currently set in state from data provided by the idp service and not from either the dosing or account service. For this reason it is important to know that an error/issue while using simpatra admin functionality does not necessarily mean there is an issue on the customer facing side of the application. When in doubt, test the bug in question using a standard organization account that does not have the simpatraAdmin flag.