-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add NOWNodes to EngineInfo #396
Conversation
113c130
to
eb82f60
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am approving this because it seems like it would work fine as-is.
There are some things that could probably be improved, though, so I left comments for those.
export interface ServerConfig { | ||
type: 'blockbook-nownode' | ||
uris: string[] | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This structure seems weird. Why not put fallbackNownodeServers?: string[]
straight into the engine info / init info?
I mean, it's always possible to invent your own custom object type using arrays, like type FakeObject<T> = Array<{ key: string, value: T}>
, but this sort of thing is rarely a good idea. Just use normal objects.
The ServerConfig
type seems to be implementing this anti-pattern, with type
as the key and uris
as the value. Rather than using string enums and arrays, it would be simpler to just use named properties right on the relevant objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because: It's easier to enumerate nominal types then fields in typescript.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, we discussed this design some more, and it makes sense if the servers need extra data, such as contract addresses or such. In that case, it might be { type: 'foo', servers: [], queryParams: '' }
, and so we want the flexibility of the array approach. This will impact the way the info server assembles the core rollup payload, so we might need a follow-up PR over there.
fb01b55
to
962f7df
Compare
0990871
to
5b2f4d4
Compare
The convention is such that if a file's main purpose is to define a interface/type by a class or factory function, then the file name should match the name of that interface. So, we remove "make" from file names, and we make some changes to interface type names to match the file name.
This is less likely to be confused with an on-chain address.
This infra is similar to accountbased currencies in that we maintain a list of server configs that can match with a specific key from initOptions. The only difference with this implementation is that there is no info-server support for this integration yet. These servers will only be used as fallback servers if WebSocket broadcasts fail.
5b2f4d4
to
fe9e6aa
Compare
This infra is similar to accountbased currencies in that we maintain
a list of server configs that can match with a specific key from
initOptions.
The only difference with this implementation is that there is no
info-server support for this integration yet.
These servers will only be used as fallback servers if WebSocket
broadcasts fail.
CHANGELOG
Does this branch warrant an entry to the CHANGELOG?
Dependencies
noneDescription
none