My project has a declarative way of defining schema and resolvers, which is maintained in a separate repository. My graphql server polls the result of this to look for updates to the schema.
Using apollo-server-express#1, I had direct access to the graphqlExpress middleware, so when the schema changed I could construct a new instance of it and throw away the old one, something like this
const { graphqlExpress } = require('apollo-server-express');
let api;
const constructAPI = () => {
try {
const newSchema = createSchema();
api = graphqlExpress(({ headers }) => ({
schema: newSchema,
}));
logger.info({ event: 'GRAPHQL_SCHEMA_UPDATED' });
};
schemaPoller.on('change', constructAPI);
module.exports = router => {
// Note that we wrap the api controller in a function that passes
// the original args through because a new api controller is generated
// every time the schema changes. We can't pass express a direct
// reference to the api controller on startup, or it will
// never update the reference to point at the latest version of the
// controller using the latest schema
router
.route('/')
.get((...args) => api(...args))
.post((...args) => api(...args));
return router;
};
In apollo-server-express#2, access to the middleware is hidden away, and there are 2 new, more declarative ways of using the library, neither of which - at first glance - appear compatible with updating the schema without stopping the server, fetching the new schema and starting again with the new data, which is downtime I'd like to avoid.
Can anyone suggest a way of getting this setup to work with apollo#2?
Related
I'm building a Web3 app while using Solana.
I'm using #solana/wallet-adapter for wallet connection
Code:
const Wallet = ({ children }) => {
// The network can be set to 'devnet', 'testnet', or 'mainnet-beta'.
const network = WalletAdapterNetwork.Devnet;
// You can also provide a custom RPC endpoint.
const endpoint = useMemo(() => clusterApiUrl(network), [network]);
// #solana/wallet-adapter-wallets includes all the adapters but supports tree shaking and lazy loading --
// Only the wallets you configure here will be compiled into your application and only the dependencies
// of wallets that your users connect to will be loaded.
const wallets = useMemo(
() => [
new PhantomWalletAdapter(),
new SlopeWalletAdapter(),
new SolflareWalletAdapter(),
new TorusWalletAdapter(),
new LedgerWalletAdapter(),
new SolletWalletAdapter({ network }),
new SolletExtensionWalletAdapter({ network }),
],[network]);
return (
<ConnectionProvider endpoint={endpoint}>
<WalletProvider wallets={wallets} autoConnect>
<WalletModalProvider>
<WalletMultiButton />
<WalletDisconnectButton />
{children}
</WalletModalProvider>
</WalletProvider>
</ConnectionProvider>
);
};
It's a basic components. Same as a presented in #solana/wallet-adapter docs
The problem:
After connecting some wallet manager(let's say Phantom, for instance), I'm getting all the information I need. But after changing wallet -- I don't see any updates in my app.
The question is
How can I handle this?
After a couple of days of research, I came to the conclusion that this is an API bug.
I found a way that allows you to find out if the account has changed or not. It can be used if it is critical for you:
const isAccountChanged = window.solana.publicKey.toBase58() !== `${your_current_public_key}`;
if (isAccountChanged) {
// do some updates
}
For now, you can create setInterval(for instance) to detect these changes. So, if isAccountChanged = true -> you need to update the users state. If it's still false -> you can wait.
fyi:
https://github.com/solana-labs/wallet-adapter/issues/49
https://github.com/solana-labs/wallet-adapter/pull/109
I have a Asp.Net Web API 2 using Token based authentication (OAuth2).
I have implemented Web API versioning using aspnet-api-versioning.
So now I have three different versions of my API. It's really great, I can now change V3 without affecting the current API.
But the /token endpoint is not versioned because it is not in my controller. It's in the Providers.
I searched but couldn't find anything helpful.
We can register more than one token endpoint in the Startup.Auth.cs
So here's what I did:
OAuthOptions = new OAuthAuthorizationServerOptions
{
TokenEndpointPath = new PathString("/Token"),
Provider = new ApplicationOAuthProvider(PublicClientId),
AuthorizeEndpointPath = new PathString("/Account/ExternalLogin"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
AllowInsecureHttp = true, //Allow HTTP to send username password.
};
app.UseOAuthBearerTokens(OAuthOptions);
OAuthOptionsV3 = new OAuthAuthorizationServerOptions
{
TokenEndpointPath = new PathString("/api/V3/Accounts/Token"),
Provider = new ApplicationOAuthProvider2(PublicClientId),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
AllowInsecureHttp = true, //Allow HTTP to send username password.
};
// Enable the application to use bearer tokens to authenticate users
app.UseOAuthBearerTokens(OAuthOptionsV3);
So now I have different token endpoint for each version.
I'm not familiar with this particular setup, but this looks like middleware. There isn't quite enough information here to provide you with a specific answer, but your goals should be achievable in one of a few ways:
Option 1 - Use the Conventions API
If you authorization endpoint is actually a controller (though I think it is not), you can use the Conventions API like so:
services.AddApiVersioning(options =>
{
options.Conventions.Controller<OAuthController>().IsApiVersionNeutral();
}
Conventions was specifically meant to deal with a scenario where a controller might be externally defined and you don't have any control over the source code.
Option 2 - Use a Custom Convention
Middleware could create actions dynamically. As long as actions are actually produced, then you can use a custom IControllerConvention. You would be passed the ControllerModel which contains the actions you need to version. Assuming this is the correct behavior, you'd be looking for matching actions in the source model and then you can apply it to the controller conventions with something like:
public class MyConventions : IControllerConvention
{
public bool Apply(IControllerConventionBuilder controller, ControllerModel controllerModel)
{
var method = // TODO: resolve the target method from controllerModel
if (method == null)
{
return false;
}
controller.Action(method).IsApiVersionNeutral();
return false;
}
}
Option 3 - In Middleware
If this is pure middleware, API versioning isn't directly supported there. You can, however, support versioning on your own if the pipeline is composed properly. Specifically, API Versioning must come before other parts of middleware that need it. This usually happens automatically, but if you need to control registration, you need to change your setup to handle it manually like this:
services.AddApiVersioning(options => options.RegisterMiddleware = false);
// ... inside application setup
services.UseApiVersioning();
The API Versioning middleware doesn't really do much of anything special. It merely adds a pipeline feature. As long as that's before your other middleware, it will be available downstream like this:
var feature = context.Features.Get<IApiVersioningFeature>();
// the raw, unparsed API version, if any
var rawApiVersion = feature.RawApiVersion;
// the parse API version; will be null if no version is specified
// or the value cannot be parsed
var apiVersion = feature.ApiVersion;
// TODO: enforce versioning policies within the middleware
Option 4 - Use the API Explorer
If none of the previous approaches will work for you, you can leverage the API Explorer extensions for API Versioning to build your configuration (as above) from discovered APIs. This would have the advantage of not being hardcoded or require changes every time you release a new version.
Your application startup configuration would change to something like this:
public void Configure(IApplicationBuilder app, IApiVersionDescriptionProvider provider)
{
foreach (var description in provider.ApiVersionDescriptions)
{
var options = new OAuthAuthorizationServerOptions()
{
TokenEndpointPath = new PathString($"/api/{description.GroupName}/Accounts/Token"),
Provider = new ApplicationOAuthProvider2(PublicClientId),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(TokenExpirationInDays),
AllowInsecureHttp = true,
};
app.UseOAuthBearerTokens(options);
}
}
Been trying to get my head around this, but can't for the life of me figure out what I'm missing.
So I want to set up keystone, but want to use angular on the front end, and I want to avoid reloading the page every time.
Got angular running quite fine and pretty quickly. But now I am trying to set up the routes on the backend for the partials, and while I can manage to get them set up to answer, I can not get them to just send the partial, whatever I do it sends the whole page back to me. with html, body, head.
So far I have managed to figure out that I need a route, so imported my uiview directory and added the following route:
var keystone = require('keystone');
var middleware = require('./middleware');
var importRoutes = keystone.importer(__dirname);
// Common Middleware
keystone.pre('routes', middleware.initLocals);
keystone.pre('render', middleware.flashMessages);
// Import Route Controllers
var routes = {
views: importRoutes('./views'),
uiviews: importRoutes('/uiviews'),
};
// Setup Route Bindings
exports = module.exports = function (app) {
// Views
app.get('/', routes.views.index);
app.get('/uiviews/index',routes.uiviews.index);
app.get('/blog/:category?', routes.views.blog);
app.get('/blog/post/:post', routes.views.post);
app.get('/gallery', routes.views.gallery);
app.all('/contact', routes.views.contact);
// NOTE: To protect a route so that only admins can see it, use the requireUser middleware:
// app.get('/protected', middleware.requireUser, routes.views.protected);
};
I think what is happening is that the pre compiler ( keystone.pre('routes', middleware.initLocals);) gets hold of it and wraps it all the way it thinks it is suppose to, but I'm not certain.
I even tried to create a uiviews.js in ./routes with just my uiroute, but that gives me 404 errors
var keystone = require('keystone');
var middleware = require('./middleware');
var importRoutes = keystone.importer(__dirname);
// Import Route Controllers
var routes = {
uiviews: importRoutes('/uiviews'),
};
// Setup Route Bindings
exports = module.exports = function (app) {
// Views
console.log('uiroutes added');
app.get('/uiview/index',routes.uiviews.index);
// NOTE: To protect a route so that only admins can see it, use the requireUser middleware:
// app.get('/protected', middleware.requireUser, routes.views.protected);
};
Any ideas?
This is more of a Express question and not of keystone.Js.
You have not said which router you want partially. and neither shared rendering code of that handler.
Any way Make sure that the template you are using does not include any other template. particularly default.jade
I finally managed to figure out what I was missing.
Technically it is not keystone.js that controls what is sent, it is handlebars. This might be obvious to everyone but me.
However, the trick is to tell handlebars not to include the layout, which is done using {layout: false}. So my uiview route looks like this (last little line does the magic):
var keystone = require('keystone');
exports = module.exports = function(req, res) {
console.log("request for index received");
var view = new keystone.View(req, res),
locals = res.locals;
console.log(locals);
// Render the view
console.log(view)
view.render('uiviews/index', {layout: false});
};
with the index.js router looking like this:
var keystone = require('keystone');
var middleware = require('./middleware');
var importRoutes = keystone.importer(__dirname);
// Common Middleware
keystone.pre('routes', middleware.initLocals);
keystone.pre('render', middleware.flashMessages);
// Import Route Controllers
var routes = {
views: importRoutes('./views'),
uiviews: importRoutes('/uiviews'),
};
// Setup Route Bindings
exports = module.exports = function (app) {
// Views
console.log('index added');
app.get('/', routes.views.index);
app.get('/partners', routes.views.partners);
app.get('/blog/:category?', routes.views.blog);
app.get('/blog/post/:post', routes.views.post);
app.get('/gallery', routes.views.gallery);
app.get('/philosophy', routes.views.philosophy)
app.get('/socialmedia', routes.views.socialmedia)
app.all('/contact', routes.views.contact);
app.get('/uiviews/index', routes.uiviews.index)
// NOTE: To protect a route so that only admins can see it, use the requireUser middleware:
// app.get('/protected', middleware.requireUser, routes.views.protected);
};
And now you can call [host]/uiviews/index and only receive a partial route.
My application uses BreezeJS, ASP.NET Web API and EF.
I'm trying to save an object using breeze, as follows:
var saveOptions = this.manager.saveOptions.using({ resourceName: "SaveLocationSettings", tag: clientId, allowConcurrentSaves: true });
var obj = self.manager.saveChanges(null, saveOptions).then(saveSucceeded, saveFailed);
I'm using a custom save method on the server side, which returns a SaveResult object. However, on the client side, the entity manager still maintains the modified state.
My controller on the Web API is a BreezeController.
According to the breeze documentation, if your custom method has the signature similar to the Breeze SaveChanges() method, it should work similar to SaveChanges() method. However, if I use the breeze SaveChanges(), the entity state gets updated properly. But my custom endpoint save does not update the entity state, although the data is saved in the database.
UPDATE:
After some investigation, I figured that this happens only with one entity type that goes to this particular save endpoint. Say, I have a 'location' object, with a collection of 'availability' associated with it, as follows:
Class Location {
public Location() {
this.Availabilities = new HashSet<Availability>();
}
}
Now from the client side, if I only change some property of the Location object, it handles the hasChanges property correctly. But if I change the Availability only or Availability along with another property of the location, then the hasChanges is not updated properly on client side.
This is my server side code that's called from the WebAPI controller:
public SaveResult SaveLocation(Location l, List<MaxAvailability> maxAvailability, int changedBy)
{
// Create a SaveResult object
// we need to return a SaveResult object for breeze
var keyMappings = new List<KeyMapping>();
var entities = new List<object> {l, maxAvailability};
var saveResult = new SaveResult() { Entities = entities, KeyMappings = keyMappings, Errors = null };
try
{
if (l.LocationId == -1)
{
// add new location
l.LocationId = this.AddNewLocationWithItsAssociatedData(l, maxAvailability, changedBy);
}
else
{
// do changes to the existing location
this.UpdateExistingLocationWithItsAssociatedData(l, maxAvailability, changedBy);
}
}
catch (DbEntityValidationException ex)
{
// Log the error and add the errors list to SaveResult.
// Retrieve the error messages as a list of strings.
saveResult.Errors = this.GetErrors(ex);
}
return saveResult;
}
I think I figured out the answer. It was due to some bad practice in my code. When modifying the availability of an existing location, instead of updating the existing record, I was deleting the existing record and adding a new one. This was causing the client side availability object and the database object to have two different states. Once it was resolved, the hasChanges() state was behaving as expected.
Last time I checked, Relay.js did not support session-based NetworkLayer (only one NetworkLayer could be used at the same time).
Thus, queue-hack (https://github.com/codefoundries/isomorphic-material-relay-starter-kit/blob/master/webapp/renderOnServer.js#L66) was required to support multiple sessions. It cannot be used in production as each render is completely blocking another render (including data fetching).
What's the current status on this issue?
Where can I follow the progress (github issues) and possibly help?
This is the GitHub issue you're looking for, and great progress has been made on making most of Relay "contextual" at this point. See that issue for more details.
Since version 0.6 isomorphic-relay (which isomorphic-material-relay-starter-kit uses under the hood) supports per HTTP request network layers, allowing to pass session data on to GraphQL server. And the important thing is that it uses isolated Relay store for each request, thus no user could see another user's private data.
Example usage:
app.get('/', (req, res, next) => {
// Pass the user cookies on to the GraphQL server:
const networkLayer = new Relay.DefaultNetworkLayer(
'http://localhost:8080/graphql',
{ headers: { cookie: req.headers.cookie } },
);
// Pass the network layer to IsomorphicRelay.prepareData:
IsomorphicRelay.prepareData(rootContainerProps, networkLayer).then({ data, props } => {
const reactOutput = ReactDOMServer.renderToString(
<IsomorphicRelay.Renderer {...props} />
);
res.render('index.ejs', {
preloadedData: JSON.stringify(data),
reactOutput
});
}).catch(next);
});
Sounds like the problem is in relay.JS which means you should start on their GitHub page if you want to help.